Hmmm good point: I cannot imagine why one project would want a different compiler plugin version or a javadoc plugin version. My problem is once you start where do you stop? All or nothing is what I would prefer so there is no ambiguity.
If it was all or nothing what would you choose?
On Aug 22, 2007, at 2:08 PM, Alex Karasulu wrote:Yeah I'm not too keen on this since different projects will be stuck on different versions of plugins.
I know reuse is a good thing but keeping the main pom light is as well. I don't want any project
specificity in this TLP level pom since it weighs down projects that might not need those terms
in the pom. Did you look at this?
http://cwiki.apache.org/DIRxDEV/top-level-pom-management-policy.htmlyes but it doesn't appear to relate to what I'm suggesting. Right now there are 2 plugin versions specified in the project pom and nothing whatever else of any use to a child project. I think either all the basic release management functionality should have its versions specified in the project pom or it should be eliminated -- right now it's providing almost no value. Why would we want different subprojects using different compiler or javadoc plugin versions? I'm just thinking of taking the stuff that every subproject has to use and putting it in project.In any case this is a really minor issue and if you are happy with things as they are I'll revert my changes to project:8-SNAPSHOTthanksdavid jencks
AlexOn 8/20/07, David Jencks < email@example.com> wrote:What would people think about moving most of the pluginManagement
into the project/pom.xml and releasing a version 8 for 1.5.1?
I think it would be even better to get more project info in there but
I'm not sure I'm prepared to do that this week. I would be able to
move a bunch of pluginManagement.