>> 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. 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. 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. --benson --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
