james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Module split up
Date Wed, 03 Feb 2010 09:52:29 GMT
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
> 



Mime
View raw message