Bernd Fondermann ha scritto:
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.
Don't worry, you're not late :-)
No commit happened yet!
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.
My main goal here is not having cycles.
So what I propose is either to use the package javadoc or to switch the
main package with the parser package reintroducing the core package (for
what is in main now).
I'm slightly in favor of the javadoc/documentation approach and leave
the parser package there (parsing is only one aspect of dealing with mime).
Any other opinion?
Again, sorry for the late feedback, but I am only these days learning
to use mime4j.
No problem, I simply created the 2 branches because it happened I had 2
days to work on that stuff and I wanted to make something concrete, but
I'm not in hurry.
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.
Yes, let's see what other thinks about the issue, first, and then we'll
decide what to do!
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
In the stream-refactoring branch I managed to make InputBuffer a
FilterInputStream and to name it BufferedLineReaderInputStream and it
now naturally belong to the stream package (if both proposals are
accepted, of course).
Thank you for reviewing,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
