I've been tearing my hair out trying to get Maven to build Eclipse RCP products. A lot of the problems I have had, as it turns out, are to do with Maven POMs that express dependencies on Eclipse artifacts with a range of versions.
Because you can't always update all your Eclipse plugins at once, it might seem to make sense to express dependencies on them not as a fixed version number but as a range. The following is a typical example (/org/eclipse/jdt/launching/3.3.0-v20070510/launching-3.3.0-v20070510.pom):
<project>
...
<groupid>org.eclipse.jdt</groupid>
<artifactid>launching</artifactid>
<name>Java Development Tools Launching Support</name>
<version>3.3.0-v20070510</version>
...
<dependencies>
<dependency>
<groupid>org.eclipse.core</groupid>
<artifactid>resources</artifactid>
<version>[3.3.0,4.0.0)</version>
</dependency>
...
</dependencies>
...
</project>
Unfortunately this only works where the version number of the actual artifact in the repository conforms to one of two patterns:
A.B.C-D
or
A.B.C-qualifier
(it is unclear whether the qualifier itself is subject to any formatting rules). In all other cases, Maven compares the artifact version number to the upper and lower bound of the range as a simple string, which actually means that version 3.3.0-v20070604 sorts below 3.3.0 and thus does not match the expression in the above example.
I may be able to fix this for individual POMs within our project repository and get the example build running, but that is not a general-purpose solution. Before long, someone on our project will bring in a dependency on some Eclipse plugin, which is obtainable from the Maven repository at Maven Central but only with a POM that contains a version range in one of its transitive dependencies.
Unfortunately, the majority of Eclipse plugins are likely to be in the Maven repository with this kind of version range dependency. The reason is that they get put there using the maven-eclipse-plugin (to-maven goal), which does not resolve OSGi Require-bundle version ranges when converting them to Maven dependencies. The latest version is meant to honour a property "resolveVersionRanges" (default is false), but I have not been able to get this to work.
And here's why - Carlos has removed the line of code that invoked the resolveVersionRanges routine.
1 comment:
I have discovered that if you use version 2.4 of the maven-eclipse-plugin to run the to-maven goal, instead of version 2.5-SNAPSHOT, the version numbers of dependencies of installed/deployed Maven artifacts are set to the actual version you have in your eclipse plugins directory. This solves at least part of the problem.
You also need to fix up the version number of the dependency on org.eclipse.pde.core in the POM of the pde-maven-plugin. Otherwise it picks up a version with version ranges in its dependencies.
Post a Comment