Comments interspersed below.
Ron
On 25/10/2010 8:26 AM, Benson Margulies wrote:
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.
Don't underestimate the desire to continue to use bad workflow and poor
project structures.
I would also add in the ease with which plug-in are created as a
negative influence in some cases.
Just because maven CAN do it does not mean that your SHOULD do it.
Sometimes the plug-in does not already exist because there is a better
way to get the workflow to do what is required.
The helpful people on this list are very good at responding to specific
questions about how to do something without asking "Why is such a
workflow required?"
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?"
Hints:
JNDI
Common libraries for chunks of shared functionality
SOA
None of these have to do with Maven directly but trying to use Maven to
solve the problems caused by not using these technologies correctly is a
lot of work and requires all kinds of gymnastics with plug-ins.
Anyone writing a custom plug-in really needs to examine why they have
wandered off the "Best Practice" road into the bushes.
It may be justified but be prepared for a bumpy ride and in the end you
may not get to your destination as quickly as you would if you followed
the "Best Practices".
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
