Niklas Therning ha scritto:
Stefano Bagnara wrote:
After your benchmark I applied the package refactoring I proposed in
MIME4J-51, so I'd like you and Oleg to try updating your client code
to see how many changes are needed and if the new structure make
sense. This is something I would avoid changing too often, so it is
better to vet it now before we write it in the stone with a release.
I'm afraid I have missed the whole "review packaging" discussion, I hope
I'm not too late. :) I'd prefer to have MimeStreamParser and
MimeTokenStream in the root package if possible. That would be the most
natural thing I think since those are by far the most central classes. I
also think ContentHandler and AbstractContentHandler could go in the
root package. With these changes the upgrade effort for me would be
close to none since what we use is probably only MimeStreamParser,
ContentHandler and BodyDescriptor. I understand that this would
introduce some cycles but I still think that it would make Mime4j a lot
easier to use for the end user. I'd rather have some cyclic dependencies
if it makes the whole thing easier to understand.
Ok, please let's discuss about this with the needed calm and timings. If
we find a release manager before we are done with this we can release
what we had just before MIME4J-51, so that we don't change packaging
multiple times.
The core goal of the refactoring was to remove circular/cyclic
dependencies for mime4j packages.
The idea behind moving the parser stuff to "parser" was that mime4j now
supports also writing mime stuff and will probably support mime DOM
handling even without any parsing, so parsing is only one of the aspects
of the library. Furtheremore we can't put classes from parser and
classes from the main package in the same package because this would
reintroduce cycles.
I say we "can't" but I simply think that if we refactor packages this is
a MUST, otherwise it doesn't worth to move stuff around and simply
should vote down MIME4J-51.
In my first proposal we had the parser classes in the main package and
the main package classes in the core package. Robert and I preferred to
invert them, Bernd was for keeping the old structure. No one else
commented so I took the "2 vs 1" as a preference.
IMHO we can invert the 2 packages very easily, we just need an agreement.
Please note that if we move mime4j.parser.* to mime4j and mime4j.* to
mime4j.core you will have anyway to update your code because 4 classes
you import (or at least MimeException and BodyDescriptor) will be moved
to core.
Unfortunately I don't see a solution [1] for leaving the current client
code unchanged and remove cyclic dependencies in packages. I wouldn't
like (this does not mean I would veto this, simply that I don't like it)
to use the current structure and simply move parser.* to the main
package because this would mean loosing my original goal.
In case of James-server we also was using MaximalBodyDescriptor that has
been moved to descriptor package.
The idea is that a repackaging is needed to improve self-documentation
of the code structure and that repackaging usually involve client code
updates. if we want to do that we have to do as soon as possible because
this is not something to do in an 1.0 release.
In order to summarize we can:
1) vote down MIME4J-51 and revert the code change.
2) keep that in trunk for a future release and try to release r680989
(and reapply r682373 and r682374)
3) move mime4j.* to mime4j.core.* and mime4j.parser.* to mime4j.*
4) leave everything as is in trunk.
5) ... any other concrete suggestion is welcome, I don't have more.
My current preference is:
#4 +1 preferred
#3 +0
#2 -0
#1 -0 hope this is not the case as I spent a lot of time refactoring
already twice the codebase for the proposal and for the real application
after I thought we had an agreement, but shit happens, and I won't vote
down a release for this.
Stefano
[1] well, a solution exists: put *everything* (83 classes) in a single
package. but this is not acceptable for me.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
