Then you often discover that Maven's cool feature, to automagically use LATEST version of plugins by default, is not that cool... new versions may be incompatible with your specific usecase, or broken completely, etc etc (I suffered this experience with maven-war-plugin version 2.1-alpha-2 as I reported in [#MWAR-181]).
Yes, you can work hard and define a corporate pom that presets version of all plugins you use. That's good, but who will remember to do that when a new plugin will be added to build ? Most people won't.
Fortunately, there is a way to keep you reminded: forbid download of "*metadata.xml" files and that's it. Maven uses this file to determine list of available versions, whenever you use a non-specific version like RELEASE or LATEST, which is the case of plugin artifacts. Without such metadata, maven fails,saying that it cannot find any version - so you immediately know that your build would be irreproducible otherwise and that it is time to extend your corporate pom.
On Apache server, you can accomplish that using mod_rewrite - just add something like this to httpd.conf:
... RewriteEngine on # strict repo: RewriteRule ^/maven2-strict/.*metadata\.xml$ - [G,L] RewriteRule ^/maven2-strict/(.*) http://my.physical.repo:8081/nexus/content/groups/public/$1 [P,L] ...
and, of course, use this in your settings.xml:
... <mirror> <id>internalRepository</id> <mirrorOf>*</mirrorOf> <name>inhouse aggregated repo</name> <url>http://my.intranet.server/maven2-strict</url> </mirror> ...
As Brian Fox from Sonatype noted, there are better alternatives to reach reproducibility:
- Nexus users can use directly its own administration interface to setup the redirect
- even better is, to use maven-enforcer-plugin with its requirePluginVersions rule; it has no impact on using commandline mojos with abbreviations
Read comments for more details.