Issue Details (XML | Word | Printable)

Key: MNG-3395
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Brian Fox
Reporter: Brian Fox
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
Maven 2 & 3

Default core plugin versions in the superpom.

Created: 09/Feb/08 04:45 PM   Updated: 13/Feb/09 04:50 AM   Resolved: 17/Mar/08 12:51 PM
Return to search
Component/s: Artifacts and Repositories
Affects Version/s: 2.0.8
Fix Version/s: 2.0.9

Time Tracking:
Not Specified

File Attachments: 1. Text File default-plugin-versions.patch (2 kB)
2. Text File default-plugin-versions.patch (2 kB)

Issue Links:
Related
 
dependent
 


 Description  « Hide

We should define the plugin versions for core and other common plugins (the apache plugins is a good place to start) in the super pom in 2.0.x to help with stability.

See here for more info.
http://www.nabble.com/Plugin-Versions-in-the-Super-pom-to15367074s177.html#a15367074



Paul Benedict added a comment - 28/Feb/08 06:25 PM

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.


Brian Fox added a comment - 07/Mar/08 02:45 PM

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


Benjamin Bentmann added a comment - 08/Mar/08 04:38 AM

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> ".


Brian Fox added a comment - 08/Mar/08 09:48 AM

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).


Paul Benedict added a comment - 09/Mar/08 08:46 AM

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


Brian Fox added a comment - 09/Mar/08 09:27 AM

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.


Paul Benedict added a comment - 09/Mar/08 10:43 AM

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


Benjamin Bentmann added a comment - 17/Mar/08 12:40 PM

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?


Brian Fox added a comment - 17/Mar/08 12:51 PM

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.


Paul Benedict added a comment - 17/Mar/08 12:59 PM

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.


Benjamin Bentmann added a comment - 17/Mar/08 01:20 PM

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.