Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Tip
titleUse <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:

No Format
<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 (again the Maven docs will tell it better than I), 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.

No Format
<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.

...