I may be wrong regarding maven3-core, but AFAIK most code (including some plugins) related to POM parsing use Xpp3Reader, as we don't provide an abstraction API for POM parsing. Such a migration to JAXB (or other), without consideration to the technical beneficts, would require a compatibility layer. Can we provide some Xpp3-compliant API on top of JAXB ?
2010/11/12 Lennart Jorelid <[email protected]> > 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. > The JSE standard is JAXB which could generate both > XML and XSD documents for all our projects. > We need only add JAXB annotations to our classes > and properties for it to happen. If we feel that > the model becomes bogged down in annotations, we > can simply create our own compound annotations > to reduce clutter. > > 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. > > 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. > > This discussion can be exemplified with the setter below, > which provides no parameter validation > (i.e. "no-op setter antipattern"), not quite a sensible > JavaDoc and no explanation of its parameter's significance. > While I believe that most of us will eventually understand > what goes on here, I suggest that overall code quality is > reduced by the generation tool. Let's move to a Java model. > > /** > * Set specifies that this profile will be activated when > * matching operating system > * attributes are detected. > * > * @param os > */ > public void setOs( ActivationOS os ) > { > this.os = os; > } //-- void setOs( ActivationOS ) > > -- > +==============================+ > | Bästa hälsningar, > | [sw. "Best regards"] > | > | Lennart Jörelid > | EAI Architect & Integrator > | > | jGuru Europe AB > | Mölnlycke - Kista > | > | Email: [email protected] > | URL: www.jguru.se > | Phone > | (skype): jgurueurope > | (intl): +46 708 507 603 > | (domestic): 0708 - 507 603 > +==============================+ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
