2010/2/2 Oleg Kalnichevski <[email protected]>: > 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
