Add a maven-artifact dependency

<dependency>
  <groupId>org.apache.maven</groupId>
  <artifactId>maven-artifact</artifactId>
  <version>3.0.3</version>
</dependency>

Then you could write something like this:

public int compare(String version1, String version2) {
  ArtifactVersion mavenVersion1 = new DefaultArtifactVersion(version1);
  ArtifactVersion mavenVersion2 = new DefaultArtifactVersion(version2);

  int result = mavenVersion1.compareTo(mavenVersion2);

  return result;
}

dk.sorokin.maksim.model_1.0.0.201012220948.jar

If you will not have a qualifier, it will always be the same jar name:

dk.sorokin.maksim.model_1.0.0.jar

In this case you may have some troubles. For example, when you run FeaturesAndBundlesPublisher with -append option. Since old and new bundle version have the same version (without added timestamp), old version will be preserved. In this case make sure to change the version of your MANIFEST.MF, when you make changes to the project without qualifier.

Sometimes you need to provide version and build information in "About" dialog of the application. You can easily create a simple properties file in your resources folder and apply filtering on it, where build version and timestamp would be automatically replaced on each maven build. But what to do when you have dozen of such project? Is there a way to do this automatically? Indeed, there is.

The idea is simple. We start by creating a Maven "template" project which would just hold a general build properties file. Then we create a parent project which would know how to intervene into a build cycle and inject build properties file. Then we simply inherit this parent project in all other projects which require such automatic build numbering injection.

As an example we will only cover project version filtering. Build timestamp can be added easily.

We start by creating the Maven "template" project, which would hold the build properties file. We create a following build.properties file in src/main/resources:

project.version=${project.version}

Now, we need to create a parent project, which would know how to intervene into a build lifecycle. But first we need to find out when the resource are being filtered in Maven lifecycle. In Official Maven Documentation in "Default Lifecycle" section we see, that this is happening during process-sources goal. So we need to inject build.properties just before that.

In our parent project pom we define the following:

...
  <build>
    ...
    <plugins>
      ...

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-dependency-plugin</artifactId>
        <executions>
          <execution>
            <id>unpack</id>
            <phase>generate-resources</phase>
            <goals>
              <goal>unpack</goal>
            </goals>
            <configuration>
              <artifactItems>
                <artifactItem>
                  <groupId>company</groupId>
                  <artifactId>TEMPLATE-PROJECT-ARTIFACT-NAME</artifactId>
                  <version>1.0.0-SNAPSHOT</version>
                  <includes>build.properties</includes>
                  <outputDirectory>${project.build.directory}/buildInfo</outputDirectory>
                </artifactItem>
              </artifactItems>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>

    <resources>
	  ...
      <resource>
        <directory>target/buildInfo</directory>
        <filtering>true</filtering>
      </resource>
	  ...
    </resources>
  </build>
...

What it does, is intervenes into build lifecycle in generate-resources phase, just before when resources are filtered. It extracts build.properties file from Maven "template" project into buildInfo folder. Then this build.properties file is being filtered and
included into deliverable.
That is it! If this parent project is inherited in other projects, build.properties file will be automatically filtered and added during Maven build.

Furthermore, we can create another project, which would know how to parse this build file. And include this parsing project as a dependency where it is needed. So we would not need to write the same build properties file parsing logic again and again.

When you change only one module and want to make a release, usually you go for parent project release, since otherwise there will be a mess having modules with different numbers. But another module was not changed! But the versioning number was increased.

Here is live example. You have a maven project. Then, you introduce an installer for it, which is also built with maven. You make this installer module a part of your application. But application installer and application itself serve for different purposes. When you fix a problem in the installer and release it, the versioning number of your application is also increased (if you go for the same versioning in the project).

The solution is simple. If you have modules which have different purposes, they should be contained in different parent projects. Or, as an alternavitve, if you are not afraid of different numbering of modules, you still can have different purpose modules under one parent.

Here is the way to do that.

Under src/main/resources create project.properties file:

version=${project.version}

In the pom.xml enable filtering:

<build>
  ...
  <resources>
    <resource>
      <directory>src/main/resources</directory>
      <filtering>true</filtering>
    </resource>
  </resources>
  ...
</build>

And all you have to do is access project.properties file from your code.

Moreover, you can add other properties such as project name and build time.
To add name of the project add following to project.properties:

name=${project.name}

To add build time in the pom.xml add:

<project>
  ...
  <properties>
    <maven.build.timestamp.format>yyyy MMM dd HH:mm</maven.build.timestamp.format>
    <buildTimestamp>${maven.build.timestamp}</buildTimestamp>
  </properties>
  ...
</project>

And in the project.properties add:

buildTimestamp=${buildTimestamp}