>> > 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. >> 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". > * 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? > * 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) 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. Thank you, Stefano
