Developers, Developers, Developers! Maksim Sorokin IT Blog

3Apr/11Off

Comparing Maven String Versions

This posts describes comparint Maven String versions. It is assumed, that you have a Maven-managed project.

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;
}
23Dec/10Off

Manifest Version — with or without qualifier?

Should MANIFEST.MF contain qualifier or not? That depends on what strategy you use in your development cycle. When you change a plugin a lot during development cycle, it is better to add append a qualifier to the end of the version. In this case, everytime you will build a plugin, it will have a timestamp added to the end of the filename, for example:

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.

18Aug/10Off

Providing Build Information Automatically for Every Maven Project

This article describes a possibility to automatically inject properties file with build information into any Maven module.

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

14Aug/10Off

Maven Versioning Problems Having Different Purpose Modules Under One Parent

If you have modules with different purpose, you eventually hit the versioning problem.

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

7Feb/10Off

Product Versioning With Maven

Each mavenized project has its own version. Sometimes it is useful to have access to the project version from the code. For instance, display project version in the about box or on the info page.

Here is the way to do that.