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 20:29:55 GMT
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


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.


View raw message