Jar Versioning and Management

I had never heard the term Jarmageddon before, but apparently after Jarmageddon, Jar (DLL) Hell ensues.

Use <properties> to store version numbers

The only real reason I authored this page was to say that where possible, it will be best to store all of the version numbers of the various jars your project depends on in your base pom. Properties look like this:

<project>
  <groupId>acme.com</groupId>
  <artifactId>acme-pom</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>pom</packaging>
  ...
  <properties>
    <propertyname>propertyvalue</propertyname>
    <spring-portlet.version>2.0.3</spring-portlet.version>
    <portlet-api.version>1.0</portlet-api.version>
  </properties>
  ...
</project>

Properties are arbitrary key/value pairs. They can store anything, including version numbers. They are interpolated (ie. variable substitution is performed).

You can use a property anywhere in your pom.xml file, or in filtered resources, or in aggregated (sub-project) pom.xml files.

When you enclose a property name with a dollar-sign and curly braces - ${propertyname} - it will be substituted with the actual value. Below the <version> used for the Spring Portlet MVC jar will be the value of the property spring-portlet.version which - as defined above - is 2.0.3. When you want to upgrade Spring, just change the value of the property and re-compile.

<project>
  <parent>
    <groupId>acme.com</groupId>
    <artifactId>acme-pom</artifactId>
    <version>1.0-SNAPSHOT</version>
  </parent>
  <groupId>acme.com</groupId>
  <artifactId>acme-portlet</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>war</packaging>
  ...
  <dependencies>
    <dependency>
      <groupId>org.springframwork</groupId>
      <artifactId>spring-portlet</artifactId>
      <version>${spring-portlet.version}</version>
    </dependency>
  </dependencies>
</project>

The point being that the property spring-portlet.version is defined in the base pom, and its value can be interpolated in sub-project poms.

Maven will, by and large, resolve issues regarding jar management. First, jar artifacts won't actually sit in the source code repository, taking up space and bandwidth. Jar artifacts will sit in a repository separate from the source code. Secondly, dependencies (jars) must be explicitly defined in your project's pom.xml file. When it comes time to build or package up your software, Maven will retrieve the jar from the remote repository, or use a locally cached copy.

Dependencies

Developers who are new to Maven might be familiar with dependencies, but may not realize how complex dependency management can be. Maven will ask you to learn about the different types, or scopes of dependencies your project can define, and it will ask you to explicitly define those dependencies in your pom. The Maven documentation can describe this to you better than I.