I've tried to come up with a 'moderate' reprocessing of this dispute before, and for some reason I'm going to try again.
The fundamental idea of Maven is that a build can be described with a small number of facts. This is possible if the right conventions are analyzed, designed, and implemented into the build system. If a build can be described as a small number of facts, XML is an unobjectional representation for those facts. If a POM fits on a page, verbosity of XML is just not an issue. Further, historically, Maven came behind Ant. If there's one thing worse that a few facts in XML, it's many, many, facts, and a small procedural language, in XML. For many purposes, and on many occasions, Maven succeeds in the 'fundamental idea' above. There is, however, a however. In some cases, POMs grow hair. Posters to this list sometimes seem to believe that every bit of that hair is illegitimate -- that it either reflects ignorance of 'the maven way,' or it reflects insufficient willingness to create new maven plugins. I think that this is an oversimplification. Start setting up a release, or the maven-eclipse-plugin, or a non-trivial web application, and you will find that your POM gets bigger and bigger and harder and harder to manage and understand. Cases that I'm familiar with include trying to cope with the interactions of <reporting/> plugins and ordinary plugins. In my opinion, XML does add a bit of salt to these wounds. However, over-focussing on the supposed intrinsic evil of XML, either on the complaint or the defense side, is a distraction. In my opinion, the real question is, "What would it take to keep 'maven way' POMs from growing and ramifying out of maintainability?" Generalize the 'main versus site' lifecycle to allow multiple lifecycle definitions, defined once, and reused in many poms? Some way to package up a gang of plugin specs for reuse? Support for 'include'? Tighter XML for common cases? My favorite in this area is goals. Oh how I wish for: <execution id='id' phase='phase' goal='goal'> ... </execution> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
