Not beening a maven developer, just a maven-newbi, but modelling with UML was pushed very high some days.
UML then RUP to use UML, then based on UML specs some CASE Tools, developed, and then we started to learn to express our demands by using a graphical notation language, AND without the need to undestand how this graphical notation is keep on store, we generate code, Java, C++ etc. just to mention two examples. Dependencies are expressed as graphical notations oall over in UML. Maven-projects are full of dependencies? Wouldn't it be nice to have a CASE Tool to show use dependecies; I know NetBeans can show dependencies. And others too. But how can I modify my dependecies using a graphical notation?How good are UML CASE Tools in modelling artefacts for maven? How good are the integrated with maven? When I look briefly at modello xml's, I have no intention to learn how to hand write such modello model xml code/text. For me this is like learnig Thai, like learning a next language (I speak Germa English French and Spain and master quite a few programming languages, so why shall I learn a next one if we can avoid it?). If you give me the proper modelo model xml code generator integrated into my NB UML CASE Tool, why shall I then need to learn modello model xml language? And if round trip engineering is in place, that may help to a) get FAST an idea about my maven core model/architecture (a because a picture tells you more then thousand words) and b) allows me to make my changes on the graphical level and generate modello model xml files to then be processed, parsed, and process as wanted. Generating code for maven core is just one example. What I want to ask is: Are you using UML or any other CASE tools today to generate modello model files for maven-core? Would that approach eventually make sense to be used to generate other maven-artifacts too, to be used from the amazing maven tool-suite, the maven-plugins? What about round trip engineering, UML - maven-artefacts - code - maven-artefacts - UML? Are we approching a more model oriented world expressed by graphical notations like UML, where a graphic tells you much more then 1000 lines of code/text, whether it is hand writen or generated code/text or xml? OR are we just on the top of the modelling-land and do we now go down-again from this top where we come from, from the wild-hand-coding-land? Standardising should be based on over-view, should be based on architectures, not tools. In this context Xpp3Reader/Writer and JAXB are just tools. How to they help to make a complex world less complex by giving me an overview? I think we have the CASE tools to day. Now we should integrate them properly with the marvelous maven world. And what would be a better example as when a developers team, developing maven, uses UML artefacts and code generation regardless if modello model xml files are considered an intermediat step to get maven-core working. Josef -----Ursprüngliche Nachricht----- Von: nicolas de loof [mailto:[email protected]] Gesendet: Montag, 15. November 2010 10:46 An: Maven Developers List Betreff: Re: Use of standards in the Maven core 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
