Archive

Archive for July, 2009

Maven Plugins magic versions (LATEST and RELEASE)

July 20th, 2009 mohan No comments

Maven 2 internally has a concept of two repositories:

  • Plugin Repositories (POM element <pluginRepository>)
  • “Standard” Repositories (POM element <repository>)

WARNING: These are just my notes, for my recollection you really don’t need to understand this nowadays, use a repository manager (like Nexus, Archiva or Artifactory) and have it proxy any remote repositories and distribute a settings.xml to your users. Also this applies to 2.0.x and may not be correct.

Summary

Here is a brief summay for the notes:

  • The magic version strings LATEST and RELEASE are applicable to plugin’s only and not dependencies.
  • When a plugin version is not given (bad idea, don’t do this) in the POM, maven will automatically look for the youngest version. This includes both SNAPSHOTS and releases. Which means if 1.2.5-SNAPSHOT and 1.2.4 (the last released version of the plugin) are available, then you get 1.2.5-SNAPSHOT.
  • Keep in mind all the above can be skewed if running your own repository manager and redirecting all repositories (via mirror settings, in settings.xml) to your own repository manager.

Plugin Repositories

This is usually encoded in POM (don’t do this, please use a repository manager) as the <pluginRepository> element. I still don’t understand the reason to partition as two repositories. I believe any plugin dependencies would be fetched from the plugin repository.
But here is the kicker:
If you have a plugin that provides a new packaging that is not part of the Maven core, which means the plugin has to be configured as <extension>true</extension>, the dependencies will be fetched from your standard repositories. Yes, very strange indeed.

Standard Repositories

This is represented in the POM (Project Object Model) with the <repository> element. Any dependency for your project (in the <dependencies> section) is resolved by consulting all the repositories configured in the <repositories> elements. Again, cannot be stressed enough, please if you are building a Maven 2 artifact and want to share it do NOT encode the <repository> or <pluginRepository> in your POM, please use a repository manager.

maven-metadata.xml

What is the connection to repositories and maven-metadata.xml? Well, I don’t know ;) . But I do know that this additional information is maintained at least for plugins, this usually contains information on what is oldest released version and youngest released version and the SNAPSHOT versions available.

Why is this all here?

So, in case you did the unthinkable of not locking down or pegging the plugin version. Maven will always download the LATEST (this is a magic version value) version of the plugin, aka, the latest SNAPSHOT version of the plugin NOT the latest RELEASE (another magic version value). Result: broken builds. Please, please lock down your versions. (NOTE: As of Maven 2.0.9 and above the core Maven plugin versions are pegged, regardless of this take control of your Maven projects and lock it down).

Example: You are using maven-zzz-plugin, all versions that are available from all the visible plugin repositories are 1.0,1.1,2.0,2.1,2.2,1.0-SNAPSHOT,2.0-SNAPSHOT,2.3-SNAPSHOT. Maven will automatically fetch 2.3-SNAPSHOT.

But there is a catch: If your Maven execution environment if after merging all the information about a particular plugin (from all the plugin repositories configured), if the RELEASE version of the plugin is younger than the SNAPSHOT version, then the RELEASE version is fetched.

Example: Say you are using the plugin maven-xxx-plugin, it has version 1.0, 1.2,1.3, 1.0-SNAPSHOT and 1.2-SNAPSHOT available after *merging* from all the repositories. If you “*don’t* provide a version, Maven will automatically fetch 1.3 version.

Categories: Plugins Tags: ,