Module split up

[Oleg Kalnichevski <ol...@apache.org>]

Folks,

Given the magnitude of changes that took place in the trunk I think we
should really try to tackle all potentially disruptive issues before 0.7
and finally really try to not move things around anymore. 

I would like to invest time into resolving MIME4J-129, MIME4J-129 and
MIME4J-158.

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
(2) Move dom.*, field.*, message, and storage packages from mime4j-core
to a new module called mime4j-dom
(3) Eliminate dependency on commons-logging in mime4j-core
(4) Look into moving o.a.j.m.storage implementation classes to a new
module, probably called mime4j-storage or some such
(5) See if the dependency on commons-logging in mime4j-dom can be
eliminated.
(6) I also would like to see ContentHandler and AbstractContentHandler
moved from  o.a.j.m.stream to o.a.j.m.parser, if possible.

Please complain loudly if you have objections to any of the proposed
changes.

Oleg 

Re: Module split up

[Stefano Bagnara <ap...@bago.org>]

2010/2/3 Oleg Kalnichevski <ol...@apache.org>:
> Folks,
>
> I am done moving things around. Please review the latest changes and let me
> know if you find anything disagreeable.

Good job!

> 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.

I just updated the package dependency chart and the proposed modules:
https://issues.apache.org/jira/secure/attachment/12434706/graph-mime4j-modulesproposal-20100203.png

The whole thing is getting a shape :-)

Stefano

Re: Module split up

[Oleg Kalnichevski <ol...@apache.org>]

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

Re: Module split up

[Oleg Kalnichevski <ol...@apache.org>]

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
> 

Re: Module split up

[Stefano Bagnara <ap...@bago.org>]

>> > 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

Re: Module split up

[Oleg Kalnichevski <ol...@apache.org>]

On Tue, 2010-02-02 at 14:36 +0100, Stefano Bagnara wrote:
> 2010/2/2 Oleg Kalnichevski <ol...@apache.org>:
> > Folks,
> >
> > Given the magnitude of changes that took place in the trunk I think we
> > should really try to tackle all potentially disruptive issues before 0.7
> > and finally really try to not move things around anymore.
> 
> I think we could plausible find a "stable" structure for the parser
> module, while staying in a "beta" stage with the dom stuff. So
> separating the modules could even help us explaining this to users.
> This is because I think on the dom side we still need more time to
> find a good design.
> 
> > I would like to invest time into resolving MIME4J-129, MIME4J-129 and
> > MIME4J-158.
>
> You repeated MIME4J-129: did you mean another one?
> 

MIME4J-131


> > 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.


> > (2) Move dom.*, field.*, message, and storage packages from mime4j-core
> > to a new module called mime4j-dom
> 
> Unfortunately I'm not sure what you're proposing is feasible.
> Otherwise I'm +1 with a similar change.
> What I mean is that (IIRC) the current parser package have
> dependencies on the dom/field packages.
> 

See above.


> 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.

* 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

* mime-storage (o.a.j.m.storage) depends on mime4j-dom 
 
Oleg

Re: Module split up

[Stefano Bagnara <ap...@bago.org>]

2010/2/2 Oleg Kalnichevski <ol...@apache.org>:
> Folks,
>
> Given the magnitude of changes that took place in the trunk I think we
> should really try to tackle all potentially disruptive issues before 0.7
> and finally really try to not move things around anymore.

I think we could plausible find a "stable" structure for the parser
module, while staying in a "beta" stage with the dom stuff. So
separating the modules could even help us explaining this to users.
This is because I think on the dom side we still need more time to
find a good design.

> I would like to invest time into resolving MIME4J-129, MIME4J-129 and
> MIME4J-158.

You repeated MIME4J-129: did you mean another one?

> 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).

> (2) Move dom.*, field.*, message, and storage packages from mime4j-core
> to a new module called mime4j-dom

Unfortunately I'm not sure what you're proposing is feasible.
Otherwise I'm +1 with a similar change.
What I mean is that (IIRC) the current parser package have
dependencies on the dom/field packages.

If I understand your proposal you want to create
mime4j-core
mime4j-dom
mime4j-storage
right? What are the dependencies between them?

I'm not sure your goal is "easy" (at least this is not only about
"splitting into modules" but also will require more refactorings). I'm
not against your proposal (in fact I'm in favor), I'm just trying to
expose "issues".

I attached a couple of graphs of the current package dependencies:
https://issues.apache.org/jira/secure/attachment/12434524/graph-mime4j-packages-20100202.png
https://issues.apache.org/jira/secure/attachment/12434523/graph-mime4j-parserdetail-20100202.png

> (3) Eliminate dependency on commons-logging in mime4j-core

+1

> (4) Look into moving o.a.j.m.storage implementation classes to a new
> module, probably called mime4j-storage or some such

+1

> (5) See if the dependency on commons-logging in mime4j-dom can be
> eliminated.

+1

> (6) I also would like to see ContentHandler and AbstractContentHandler
> moved from  o.a.j.m.stream to o.a.j.m.parser, if possible.

+0 (didn't look at this, but probably it is correct)

> Please complain loudly if you have objections to any of the proposed
> changes.

I guess I didn't get what you want to do because it seems unfeasible,
so I hope you can detail what packages ends in each module you propose
to create and what their interdependencies are.

Stefano