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]
