PluginManagement in ASF pom
Hi folks, I just spot the r766947 [1] of the ASF pom which add a pluginManagement tag for all ASF projects. Some questions: - some plugins like modello-maven-plugin or plexus-maven-plugin are more specific for Maven projects than ASF projects. Why not move them in the Maven pom? Why not external ASF plugins like tools-maven-plugin from geronimo project are not included? - some plugins like antrun-plugin are also defined in the super pom [2]. Why defining them twice? The maintenance will be hard: for instance the version of the maven-clean-plugin is different between super pom and asf pom... - some plugins are not included in the super pom, asf pom or maven pom. Brett told me on IRC that ant-plugin is not a common plugin. I am fine for ant-plugin but nothing is defined for eclipse/idea plugins which are commons IMHO. So what are common plugins for all asf projects and common plugins for Maven projects? IMHO I think it is the responsibility of Maven to provide a super pom but each ASF project should define its own pluginManagement list. WDYT? Cheers, Vincent [1] http://svn.apache.org/viewvc?view=revrevision=766947 [2] http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PluginManagement in ASF pom
On Tue, Jun 9, 2009 at 9:25 AM, Vincent Sivetonvsive...@apache.org wrote: Hi folks, I just spot the r766947 [1] of the ASF pom which add a pluginManagement tag for all ASF projects. Some questions: - some plugins like modello-maven-plugin or plexus-maven-plugin are more specific for Maven projects than ASF projects. Why not move them in the Maven pom? Why not external ASF plugins like tools-maven-plugin from geronimo project are not included? I simply moved most of our lock down list from the maven pom up to the apache pom. It doesn't hurt them to have the extra plugins, but if they are truely maven specific, i'll pull them back down today when I update everything for the source-release bundles. - some plugins like antrun-plugin are also defined in the super pom [2]. Why defining them twice? The maintenance will be hard: for instance the version of the maven-clean-plugin is different between super pom and asf pom... The super pom is for maven users in general, we should define our own destiny just like we tell our users to do. The rate at which we update the super pom should be very slow, leaning towards stable releases and never inserting alpha/beta when there is a final release available. The same is not true of Maven, we can use whatever we want. So for me it's not at all a concern that they are in two places. Super pom = everyone, ASF/Maven pom = our corporate pom. - some plugins are not included in the super pom, asf pom or maven pom. Brett told me on IRC that ant-plugin is not a common plugin. I am fine for ant-plugin but nothing is defined for eclipse/idea plugins which are commons IMHO. So what are common plugins for all asf projects and common plugins for Maven projects? We picked only the plugins that are bound by default to a lifecycle or are frequently bound by users, such as dependency and enfocer. Things like eclipse and idea are not frequently bound to a phase and so not locking them down is ok. If you feel strongly they should, then go for it...I was attempting to lock down the minimum required to produce stable builds for the users, and not lock down the world. IMHO I think it is the responsibility of Maven to provide a super pom but each ASF project should define its own pluginManagement list. WDYT? Yes they should, but what I found in helping new projects is the hurdle to get to a consistent ASF release was too high. This way they can choose to use a sane set of defaults we know work for ASF projects and go from there. Taking everything back out is just going to make everyone's life harder. Cheers, Vincent [1] http://svn.apache.org/viewvc?view=revrevision=766947 [2] http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PluginManagement in ASF pom
I've been working on converting geronimo projects to use the apache 6 pom and think that the set of plugins tied down there is a very usable choice and makes maintenance of geronimo poms a lot easier. I certainly don't think stuff like eclipse and idea plugins belong in any root poms. For these in particular they are both AFAICT superseded by the built in idea tooling and m2eclipse. thanks david jencks On Jun 9, 2009, at 8:53 AM, Brian Fox wrote: On Tue, Jun 9, 2009 at 9:25 AM, Vincent Sivetonvsive...@apache.org wrote: Hi folks, I just spot the r766947 [1] of the ASF pom which add a pluginManagement tag for all ASF projects. Some questions: - some plugins like modello-maven-plugin or plexus-maven-plugin are more specific for Maven projects than ASF projects. Why not move them in the Maven pom? Why not external ASF plugins like tools-maven- plugin from geronimo project are not included? I simply moved most of our lock down list from the maven pom up to the apache pom. It doesn't hurt them to have the extra plugins, but if they are truely maven specific, i'll pull them back down today when I update everything for the source-release bundles. - some plugins like antrun-plugin are also defined in the super pom [2]. Why defining them twice? The maintenance will be hard: for instance the version of the maven-clean-plugin is different between super pom and asf pom... The super pom is for maven users in general, we should define our own destiny just like we tell our users to do. The rate at which we update the super pom should be very slow, leaning towards stable releases and never inserting alpha/beta when there is a final release available. The same is not true of Maven, we can use whatever we want. So for me it's not at all a concern that they are in two places. Super pom = everyone, ASF/Maven pom = our corporate pom. - some plugins are not included in the super pom, asf pom or maven pom. Brett told me on IRC that ant-plugin is not a common plugin. I am fine for ant-plugin but nothing is defined for eclipse/idea plugins which are commons IMHO. So what are common plugins for all asf projects and common plugins for Maven projects? We picked only the plugins that are bound by default to a lifecycle or are frequently bound by users, such as dependency and enfocer. Things like eclipse and idea are not frequently bound to a phase and so not locking them down is ok. If you feel strongly they should, then go for it...I was attempting to lock down the minimum required to produce stable builds for the users, and not lock down the world. IMHO I think it is the responsibility of Maven to provide a super pom but each ASF project should define its own pluginManagement list. WDYT? Yes they should, but what I found in helping new projects is the hurdle to get to a consistent ASF release was too high. This way they can choose to use a sane set of defaults we know work for ASF projects and go from there. Taking everything back out is just going to make everyone's life harder. Cheers, Vincent [1] http://svn.apache.org/viewvc?view=revrevision=766947 [2] http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
