On Sun, Jul 13, 2008 at 21:23, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: >> >> On Sat, Jul 12, 2008 at 5:48 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >>> >>> Robert Burrell Donkin ha scritto: >>>> >>>> On Thu, Jul 10, 2008 at 6:02 PM, Stefano Bagnara <[EMAIL PROTECTED]> >>>> 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. +1 Bernd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
