Ban Maven 3.0 through 3.0.3, also fix prerequisites in parent pom

[stephenc]

BTW, it is a really sucky plan to list every plugin in the world in the parent pom. A better plan is to list the lifecycle plugins and the one or two "important" non-lifecycle plugins, e.g. maven-release-plugin, the eclipse plugin (to give the lifecycle hints) and the reporting plugins (if we are using them for reporting)... IOW if a plugin is used in one/two projects then it should really be only defined in those projects

Here is the output from versions:display-plugin-updates...

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Jenkins 1.26-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- versions-maven-plugin:1.3.1:display-plugin-updates (default-cli) @ jenkins ---
[INFO]
[INFO] The following plugin updates are available:
[INFO] com.cloudbees:maven-license-plugin ....................... 1.3 -> 1.4
[INFO] maven-assembly-plugin .................................. 2.2.1 -> 2.3
[INFO] maven-checkstyle-plugin .................................. 2.6 -> 2.9
[INFO] maven-dependency-plugin .................................. 2.3 -> 2.4
[INFO] maven-deploy-plugin ...................................... 2.6 -> 2.7
[INFO] maven-eclipse-plugin ..................................... 2.8 -> 2.9
[INFO] maven-gpg-plugin ......................................... 1.3 -> 1.4
[INFO] maven-idea-plugin ............................... 2.2 -> 2.3-20100704
[INFO] maven-jar-plugin ....................................... 2.3.1 -> 2.4
[INFO] maven-javadoc-plugin ................................... 2.8 -> 2.8.1
[INFO] maven-pmd-plugin ......................................... 2.5 -> 2.7
[INFO] maven-surefire-plugin ................................... 2.9 -> 2.12
[INFO] maven-surefire-report-plugin ............................ 2.9 -> 2.12
[INFO] maven-war-plugin ....................................... 2.1.1 -> 2.2
[INFO] org.codehaus.cargo:cargo-maven2-plugin ............... 1.1.2 -> 1.2.0
[INFO] org.codehaus.gmaven:gmaven-plugin ........................ 1.3 -> 1.4
[INFO] org.codehaus.mojo:exec-maven-plugin .................... 1.2 -> 1.2.1
[INFO] org.codehaus.mojo:findbugs-maven-plugin .............. 2.3.2 -> 2.4.0
[INFO] org.codehaus.mojo:gwt-maven-plugin ................. 2.3.0-1 -> 2.4.0
[INFO] org.jenkins-ci.tools:maven-hpi-plugin .................. 1.74 -> 1.79
[INFO] org.mortbay.jetty:maven-jetty-plugin ........... 6.1.26 -> 7.0.0.pre5
[INFO]
[INFO] All plugins have a version specified.
[INFO]
[INFO] Project defines minimum Maven version as: 2.2.1
[INFO] Plugins require minimum Maven version of: 2.2.1
[INFO]
[INFO] No plugins require a newer version of Maven than specified by the pom.
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.374s
[INFO] Finished at: Tue Feb 14 10:01:14 GMT 2012
[INFO] Final Memory: 12M/81M
[INFO] ------------------------------------------------------------------------

I will leave it to others to test these updates.

Note, I think as a minimum remove the maven-idea-plugin as that is completely deprecated for some time now.

[stephenc]

You could put it in a release profile and then when a contributor comes to make a release.... bang!

I prefer to state up front: "get your arse off Maven 3.0 through 3.0.3" that way you know you can always release... but then I prefer not to list every plugin and their mother in the parent pom... and yet that's exactly what is being done in this pom.

[ghost]

The reason we code a default version for almost all plugins is because most Jenkins plugins do not code them. Most of Jenkins ignores or doesn't understand best practices for Maven. By providing them as properties, it allows the least friction for someone who knows what they are doing to override the default version (by simply overriding the property). Also, an even less compelling reason is that, for many M2E releases, not having all versions coded would prevent project import in Eclipse.

Finally, there is http://ci.jenkins-ci.org/job/jenkins_pom/lastBuild/console which runs versions:display-plugin-updates and is executed at least @Weekly, but also on a SCM poll.

I am +1 for this change. :-) Will just wait a day or so for others to peek.

[stephenc]

Hmmmm.... somebody should check if the added enforcer rule will conflict with M2E though... I'm sure there is some trick that (an M2E user) can disable the added rule from within M2E

[ghost]

I wonder if the pluginExecution at https://github.com/jenkinsci/pom/blob/master/pom.xml#L369 is what you mean? If some user does something tricky to bypass the requirement, not much we can do; but we want to make sure that the Jenkins on Jenkins builds are the canonical / blessed versions. I think. :-)

[stephenc]

Yep that "should" prevent the enforcer from stopping M2E from building if M2E is using an embedded version of maven between 3.0 and 3.0.3...

IOW people would still be able to open the project with M2E ;-)

Somebody should try opening the project with M2E.... I'm an IntelliJ user, so don't have an M2E install handy

[ghost]

I was able to import without error a fresh copy of this project, with and without the patch applied, to my Eclipse instance:

Version: Indigo Service Release 1; Build id: 20110916-0149
M2E Embedded :v1.0.1.201106291304
M2E * v1.0.100.20110804-1717

So, let's go go go with this one! :-) Last call for objections??