[regression] Plugin versions defined in a lifecycle mapping are not respected

Personally I didn't even know you could put a version into the lifecycle, I've never seen that done.

Second, I always subscribe to the theory that "closest" wins. In the inheritance case, it means things in my pom override my parent pom, which overrides the grandparent etc. I think in this case, the pom is "closer" than the lifecycle and therefore it should win as is happening in the 3.x case. In otherwords, if I use a lifecycle that defines a version but need to tweak the version how would I do it? The pom is my only vechicle for overriding it.

Second, I always subscribe to the theory that "closest" wins.

It's more than a theory. It's documented on Maven's web site it's the only dependency resolution strategy currently supported.

I wasn't referring to dependency resolution strategies here. The closest theory applies to many things Maven does, particularly inheritence:

My pom is closer than my parent.
My parent is closer than my grandparent.
My grandparent is closer than my corporate pom.
My corporate pom is closer than the super pom.

Above logically represents my "effective pom".

I'm asserting that the "effective pom" is closer than the lifecycle version definition as it applies to this issue.

Brian, to your question "how would I do it"? If dependency management can't alter it, what can? After thinking about it, I would agree that the POM plugin management should be able to override.

Fixed in r932609.

Benjamin's fix for Maven 3.0-beta-1 removes several (why not all?) plugins from the pluginManagement section in the Maven super POM. Instead, packaging type specific artifact handlers are used. But of course this is done only for 'core' packaging types. For others the latest plugin version is used (e.g. for nexus-plugin packaging type). I think that's a critical regression because not all builds are reproducable any more.

A build that relies on the super POM default versions is generally not reproducible unless one sticks to the proper Maven version having the expected plugin versions. There is only one way to achieve reproducibilty, specify the desired plugin versions in POMs under your control.

Yes, that's exactly what I expect: Given a fixed Maven version the set of 'standard' plugins should be stable as it was intended with MNG-3395. With your recent patch that assumption isn't valid for every packaging type any more, right?

Ok. Where can I find an authoritative list of all 'standard'-plugins to configure them in my corporate parent's pluginManagement?

Is it

maven/maven-3/trunk/maven-core/src/main/resources/META-INF/plexus/artifact-handlers.xml
maven/maven-3/trunk/maven-core/src/main/resources/META-INF/plexus/components.xml

?