On 25/10/2010 1:46 PM, Benson Margulies wrote:
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.
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.
Ron,
You seem to want to take an extreme view here, in which you believe
that absolutely every case of Maven complexity (whether in POM or in
Plugins) results from mistakes. Is that really the position you want
to take, or are you just looking to be emphatic that *many* of the
distress-calls here are really because of mistakes.
I am probably a bit over dramatic.
I do find it hard to believe that there are so many ways to assemble and
run Java applications.
I suspect that if we had a set of Best Practices for developing
applications with Maven, a lot of grief could be eliminated.
I do get a bit overwrought when I read that people are having trouble
with Maven because Operations has to modify POM files or that someone is
upset about having to edit XML but will not just switch to an IDE that
includes all the editors that you need or people having trouble
detecting dependency conflicts when there is a free IDE that does that.
Maven is a great tool until you try to bend it or try to insert it into
a workflow without examining the changes that you should make to the
projects and workflows to get the benefits.
If one does not want change, then Maven will not be their friend and
they should stick with Ant.
Someone of us have to arrange interoperation with things we don't
control, and which do misuse some of these technologies. We can't just
yell at the sources. We have to come up with something.
Have a look, some time, at the POM structure at cxf.apache.org. The
shared parent is over 1,500 lines. A notable fraction of that is
dependency exclusions, which in some cases are repeated, over and over
and over, because all of the Spring artifacts have all of the same
unwanted dependencies.
We use CXF and I know that they have some packaging issues.
I would certainly look at how to repackage their application in a larger
number of POM that were:
1) more stable
2) smaller
They should also look at better management of property files.
I do appreciate the fact that if you look hard enough, you can find a
consolidated jar for CXF that does give a full and consistent set of
property files.
It is also very easy to use and quite reliable and robust.
Our portal has over 60 POMs but the parent is very small (only plug-in
dependencies and repo information) and each project POM has only 3-6
dependencies that never change except for their own version and the
version of the core software release which is held in a single property
and used to select the appropriate aggregate libraries.
The projects pick up Spring, Hibernate, Tomcat, MySQL in a single
dependency which actually depends on several other POMs.
These hardly ever change and are very simple.
We centrally manage the dependency on third party libraries so the
developers do not have to worry about the 50+ tools that make up our
core set of third party libraries.
We only use 3 or 4 of the most common and standard plug-ins and yet get
to build and deploy a large portal application.
We have no custom plug-ins.
Another source of complexity is the limitations of aggregation. We
can't get the right javadoc by just aggregating. We have to package up
with the maven-source-plugin, then unpack, and regenerate the javadoc.
This is an area that we have not looked at since we are using Eclipse
and it can navigate the libraries better than Javadocs, for what we need.
--benson
---------------------------------------------------------------------
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]
