Oleg Kalnichevski wrote:
On Wed, 2010-02-03 at 01:34 +0100, Stefano Bagnara wrote:
I would like to tackle the issues in several steps:
(1) Move MaximalBodyDescriptor from o.a.j.m.parser to o.a.j.m.dom
I don't think this is correct: MBD includes parsing implementation
details, while IMO dom is intended to only contain "api" (in form of
base/abstract classes and interfaces).
MaximalBodyDescriptor appears to be the only thing that ties the parser
packages with the field package. As far as I am concerned it does not
matter where it ends up, as long as its new location enables the parser
package to be decoupled from the field package. It can be
o.a.j.m.dom.parser, o.a.j.m.dom.impl or o.a.j.m.whatever. Feel free to
suggest a better home / package name.
As I commented in JIRA I'm fine with moving it out from parser and I
find your refactoring (introducing a factory) a good way to do this.
Let's avoid the "dom" tree as MBD doesn't have anything to do with the
dom.
My suggestion is to move it to the o.a.j.m.field package. Otherwise
o.a.j.m.message or at last create a new package for it.
Either works for me. For the time being I left MBD at its original
location.
I am going to commit a clean-up version of my original patch tonight, if
I hear no objections by then. You can review the final version of the
patch attached to MIME4J-129. It looks like JIRA notification do not get
sent out due to maintenance work being done.
As the next step we can decide what package MBD should go to.
If I understand your proposal you want to create
mime4j-core
mime4j-dom
mime4j-storage
right? What are the dependencies between them?
* mime4j-core (o.a.j.m.util, o.a.j.m.io, o.a.j.m.codec, o.a.j.m.stream,
o.a.j.m.parser) has no dependencies.
+1
maybe mime4j-parser is more descriptive than "core".
I agree mime4j-parser would be more descriptive but can live with
mime4j-core as well.
* mime4j-dom (o.a.j.m.field.*, o.a.j.m.field.dom.*, o.a.j.m.message)
depends on mime4j-core and possibly commons-logging
While we are here I'd add another module:
- mime4j-dom including only the DOM "api": o.a.j.m.dom tree (currently
this need a dependency on mime4j-core,but I think we should aim
removing this dependency and using a different MimeException in the 2
modules)
- mime4j-message for everthing else (message+field).
WDYT?
I am not sure there would ever be an alternative implementation of the
DOM API, but I can certainly live with dom and message being it separate
modules.
* mime-storage (o.a.j.m.storage) depends on mime4j-dom
Currently "o.a.j.m.message" depends on storage, so I'd say our option
is to make "mime4j-storage" dependant on "mime4j-core" and
"mime4j-message" would depend on "mime4j-storage". (of course this
could be changed if we add some refactoring like you elegantly did in
the maximalbodydescriptor stuff)
Works for me that way, too.
I think that splitting into modules will give us the ability to make
the parser more stable while we keep more freedom to shape the
remaining "younger" modules, so I'm happy to see this.
Cool. Sounds like a plan to me.
Oleg
Thank you,
Stefano
Folks,
I am done moving things around. Please review the latest changes and let
me know if you find anything disagreeable.
If I hear no objections I'll proceed with moving o.a.j.m.field.*,
o.a.j.m.field.dom.*, o.a.j.m.message classes to a separate module.
Later, that module can further be split into dom, message and storage.
Oleg
