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? Alex On 8/22/07, David Jencks <[EMAIL PROTECTED]> wrote: > > > 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.html > > > yes 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-SNAPSHOT > > thanks > david jencks > > > Alex > > On 8/20/07, David Jencks <[EMAIL PROTECTED]> 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. > > > > thanks > > david jencks > > > > > >
