I am working on Project Dash, in particular, using a set of tools for importing Eclipse packages (for example, org.eclipse.swt.gtk.linux.x86_64_3.6.2.v3659b.jar ) into the Maven 2 repository. We ran the tools over the weekend and now Result: Maven 2 test repository containing most of Eclipse 3.6.2 .
During the conversion, we encountered a problem without a simple solution: most Eclipse packages either do not request a specific version or request a range of versions. So, we have both options:
Require-Bundle: org.eclipse.core.runtime
and
Require-Bundle: org.eclipse.core.runtime;bundle-version="[3.2.0,4.0.0)"
During the conversion, the tools collect all versions of all packages, and if we need to write POM for the top example, we will write out the version that we collected (this will be 3.6.2 in this example). In lower case, we leave the version range one. There are no problems so far.
Now a new version will be released, say 3.7. When we convert this, a new version 3.7.0 of the first POM is created, and it gets a dependency on org.eclipse.core:org.eclipse.core.runtime:3.7.0 , and the second is created with the same version range as before.
Note. We now have four POMs (two for 3.6.2 and two for 3.7). One of them depends on core.runtime 3.6.2, one on 3.7.0 and two version ranges [3.2.0,4.0.0)
This is published and you are not changing anything on your side. You do not upgrade to 3.7.0!
Now we have a problem: if you use these two artifacts with version 3.6.2 in your build, then the first one will still use the base runtime 3.6.2, because it is locked.
But the second one will update the Maven metadata and see “oh, we have 3.7 for this too”, download it and hack, you will get org.eclipse.core:org.eclipse.core.runtime:3.7 and org.eclipse.core:org.eclipse.core.runtime:3.6.2 into your classpath without changing anything on your side .
This is bad. How should we solve this?