On 13/11/2010, at 12:57 AM, Lennart Jorelid wrote: > Hello all, > > I must confess I appreciate standards in larger projects. > Unless there are solid technology-based reasons not to use > existing standards, I say we should strive to use standards > as often as we can. If we do, we can acquire better > feedback and more informed suggestions for improvement. > > We use quite a few nonstandard patterns and components within > the Maven3 core - so let me suggest some refactoring ideas, > which I believe will simplify and augment Maven's internals > in upcoming releases. > > Model improvements: > a) Xpp3 --> JAXB. > We use Xpp3 to move entities to/from XML.
This isn't quite the right comparison. Xpp3 is a pull parser, a precursor to StAX. There was this issue to migrate: http://jira.codehaus.org/browse/MNG-2255. However I have a feeling it was undone in the process of Maven 3 dev't. This is still worth doing IMO, though as Nicolas says we need to keep the old API around since plugins depend on it. > > > b) .mdo --> .java. > We use Modello to generate large portions of the > mainly static central parts of Maven. I believe we > would do better without generated code within the > Maven distribution, for 3 reasons: > > 1) Java is simple to read, understand and refactor. > XML source files - such as Modello's - are neither. > For that reason alone, we should contemplate removing > a code generation tool. Moreover, to properly handle > changes in the Maven model, one needs to understand > Modello. This increases the time required to get started > in committing patches and ideas to the Maven core/model. > > 2) The Maven model is largely stable, so code generation > shouldn't really be needed. It's easier just to remove > the code generation and commit well-written Java code. This also somewhat negates against your 1st point :) > > 3) Generated code tends to contain quite a number of > no-op setters/getters (i.e. bloat), take poor use of > OO constructs such as inheritance (we generate no > abstract classes with common/template methods for use > in several subclasses) and provide somewhat poor javadoc. I assume you mean here to use JAXB instead, rather than maintaining a hand generated parser/writer? I don't disagree for a new project. It might be worth trying now that we support Java 5 and have a wider set of tests. That said, to date, I think the reason it hasn't been tried is that it's unlikely to provide substantial value relative to the work involved. It is working fine at the moment and rarely requires modification. You'd need to check not only that the behaviour and performance matches, but that the generated XPP3 reader/writer can be mapped to the new code and still work within plugins, etc. At the same time, you're adding new dependencies that previously weren't required (unless we start requiring Java 6...). I'm not sure it's worth it, even aside from the debate of the merits of using JAXB vs. code generation. This would all be more relevant to discuss in the context of changing the way the POM & metadata are handled (a discussion I'm yet to catch up on unfortunately). If that demands some changes to the way we are processing them that these could help with it would make more sense. My $A0.02... - Brett -- Brett Porter [email protected] http://brettporter.wordpress.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
