james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: [mime4j] Review Packaging
Date Wed, 16 Jul 2008 20:53:31 GMT
On Sun, Jul 13, 2008 at 21:23, Stefano Bagnara <apache@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>> On Sat, Jul 12, 2008 at 5:48 PM, Stefano Bagnara <apache@bago.org> wrote:
>>> Robert Burrell Donkin ha scritto:
>>>> On Thu, Jul 10, 2008 at 6:02 PM, Stefano Bagnara <apache@bago.org>
>>>> wrote:
>>>>> Stefano Bagnara ha scritto:
>>>>>> B] our root package included classes from mixed layers/dependencies.
>>>>>>  From the class dependencies graph it was almost obvious some
>>>>>> different
>>>>>> classification:
>>>>>>  - core:
>>>>>> BodyDescriptor/MutableBodyDescriptor/ContentDescriptor/MimeException
>>>>>>  - util: ByteArrayBuffer/CharArrayBuffer
>>>>>>  - everything else.
>>>>>>  So I moved the 2 utils to util and the 4 core classes to a new "core"
>>>>>> package.
>>>>> I was just wondering if moving the "root" package to mime4j.parser and
>>>>> the
>>>>> new "core" package to the root package would be a better alternative.
>>>> i like the sound of this better
>>> Should I create a branch for the "reorganization" so that we can better
>>> evaluate the final result?
>> feel free to grab a branch to demonstrate so long as you delete it
>> afterward and we don't merge anything
> Here we are:
> http://svn.apache.org/repos/asf/james/mime4j/branches/repackaging-proposal/src/main/java/org/apache/james/mime4j/
> vs
> http://svn.apache.org/repos/asf/james/mime4j/trunk/src/main/java/org/apache/james/mime4j/

Sorry, I missed this mail until now. It still deserves feedback from
me, although commits have already happened, and good so.

> I tried to follow Bernd suggestion and limit the use of the util package
> reintroducing the decoder package and adding stream and storage package.

Thanks!, +1

> I left in the main package only 4 *very core* classes and moved most of the
> remaining classes to the parser package.

For me, from a user perspective, MimeStreamParser.java and
MimeTokenStream.java are the most central classes, so they deserve
being easily found - at best in mime4j. Alternatively, we could have a
package javadoc in mime4j referring to these classes, ideally with
some example code.

Again, sorry for the late feedback, but I am only these days learning
to use mime4j.

> I checked that the organization in the branch does not have cyclic
> dependencies.

My last proposal might interfer with this specific architectural goal.
I am not so much a dependency matrix afficionado but I can live very
well with what you have come up with until now.

> What do you think about the result?

Look really good, overall. Thanks!

> I also think that util.InputBuffer belongs to the stream package, but I'm
> working on this as another unrelated issue.



To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message