james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Module split up
Date Tue, 02 Feb 2010 13:36:04 GMT
2010/2/2 Oleg Kalnichevski <olegk@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

Mime
View raw message