Default core plugin versions in the superpom.

Brian, when this is complete, please update the documentation to publicly reveal the versions. The information would probably be most appropriate as a table in the release notes page.

initial revision committed. Waiting for javadoc release before making this final.

initial revision committed.

The maven-clean-plugin and the maven-plugin-plugin are definitively missing since these are employed by the default lifecycle bindings. If the plugin tools get out in time, the maven-plugin-plugin could be updated to 2.4 then.

The maven-enforcer-plugin and the maven-release-plugin might be added as well given their popularity.

Not addressed by the patch:
Was the plugin list meant to be sorted alphabetically? Currently, install-plugin listed after javadoc-plugin and resources-plugin listed after surefire-plugin.

Certain lines have trailing whitespace that could be removed, e.g. search for "plugin> ".

Thanks for reviewing. I overlooked release,clean and plugin. The enforcer is going to change soon and it's about best practices, this one shouldn't be locked down (if they are using it, they should know to lock it).

I'd also like to see added:
maven-archetype-plugin
maven-resources-plugin
maven-help-plugin

Resources is in there, or it should be. IMO, archetype is evolving too quickly to lock it down. Since it is primarily used from the command line, this won't hurt repeatability of builds. Locking down help doesn't seem to provide any benefit either.

Brian, you were right about resources plugin. I missed it because it wasn't in alphabetical order.

I overlooked release,clean and plugin

Your recent commit r637973 only included version updates for exising plugins and reordering of resources-plugin. Still missing are clean-, plugin- and release-plugin. From your previous comment, I deduce this is not intended, isn't it?

I'm not really sure if plugin is required but I added it. Thanks for pointing out release...missed it again. What's the benefit to locking down clean? My goal isn't to lock everything down, just the stuff that really affects builds.

Clean can really affect builds. Especially because Windows holds locks on directories that are "opened" in other processes. The latest version of the clean plugin can deal with this.

My goal isn't to lock everything down

Sure you shouldn't lock down all existing plugins, but please do this for all plugins that have bindings to the various build packagings. The packaging "maven-plugin" uses maven-plugin-plugin and hence should be locked down. Likewise, maven-clean-plugin is automatically bound and should have a default version in the super POM for the novice users to get build reproducibility.

What's the benefit to locking down clean?

You could have also questioned "What's the benefit to locking down build plugin XYZ?" and the answer would be the same: a reproducible build. Reproducibility also includes the little aspect of stability. If clean-plugin-X works but clean-plugin-Y fails the build, this is not reproducible. Just to be clear: I don't want to upset anybody but please let's be honest, the implication "version X worked so version Y will work, too" is just utopie. This in mind, please consider that clean is executed by the release-plugin.