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 >
