Community
Participate
Working Groups
Currently, an OSGi dependency com.acme.bundle;bundle-version="1.2.3" is translated into a Maven dependency <version>1.2.3</version>. The OSGi semantics of this is "use version 1.2.3 or any newer version". However, the Maven semantics is "I can work with any version, but 1.2.3 would be fine". Apart from the semantic mismatch, there is also the problem that Maven does not attempt to look up the latest version of com.acme.bundle if no other (ranged) dependencies to com.acme.bundle are present. Instead, it simply queries all repositories for version 1.2.3. In the case of Eclipse bundles, there is never such a bundle, because they all have qualifiers. Thus, dependency resolution fails. The correct way to translate the dependency would therefore be: <version>[1.2.3,)</version> Not only are the OSGi and Maven versions now semantically equivalent, but Maven also attempts to find the latest version of com.acme.bundle and finds the variant with the qualifier.
Created attachment 207476 [details] Patch to produce version range This patch implements the proposed solution.
I cc'ed Dennis because he's currently trying to produce a working Maven repo for Xtext. And I am trying to use it ;-) With this patch for this bug and the one for bug #364141 I was able to produce a fully functional Maven repository containing the Indigo repo and the TMF Xtext and MWE update repos. Maven could consume these artifacts without any additional manual tweaking. I'd argue that we (or the foundation, or any Maven-affiliated factions within) should finally be able to tackle bug #283745.
I think that this is a bit more complicated than the attached patch. OSGi stipulates that the lack of qualifier means the lowest possible qualifier. Maven on the other hand, treats the lack of qualifier as the final release, i.e. lack of qualifier is the highest possible qualifier. Buckminster provides two very similar version types. One for OSGi that strickly follows the OSGi semantics, and one named 'Triplet' with semantics similar to how Maven sees things. Those versions can be compared. An OSGi 1.0.0.<some qualifier> is always less than a Triplet 1.0.0 <missing qualifier> So, if anything should be done here, it's sorting out the confusion between when to use OSGi semtantics and when to use Triplet semantics.
(In reply to comment #3) > I think that this is a bit more complicated than the attached patch. > > OSGi stipulates that the lack of qualifier means the lowest possible qualifier. > Maven on the other hand, treats the lack of qualifier as the final release, > i.e. lack of qualifier is the highest possible qualifier. > Hmm, puzzler. You are correct, of course. But OTOH, Maven *does* resolve a 1.2.3.20110617 JAR for a version range of [1.2.3,). Following your argument, 1.2.3.20110617 would be less than 1.2.3, so it should not be resolved. Then I re-read the docs [http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges]. And it turns out that an OSGi qualifier is not a Maven qualifier. The Maven version is defined as <major>.<minor>.<revision>([ -<qualifier> ] | [ -<build> ]). Note the dash for the qualifier instead of the dot. So we're not producing a Maven qualifier and thus resolution works. I am pretty much surprised about this finding... Does this make sense?
This information is new to me. The Triplet versus OSGi debacle was something that we debated and created a solution for long before Maven discovered the virtue of using version ranges :-) As opposed to the OSGi version, the Triplet version can handle both dash and dot. I've seen both being used in Maven. If Maven resolves 1.2.3.20110617 JAR for a version range of [1.2.3,), then I wonder what happens with the opposite. Does it find 1.2.3 for range [1.2.3.20110617,) ? If so, then the answer to your question is, no it doesn't make sense unless they've decided to completely remove the qualifier when range semantics are used.
It seems Maven 3 has not much to do with Maven 2 version-resolution-wise... In the presence of com.acme.bundle in versions 1.2.3 and 1.2.3.v20111010, the following is true (tested empirically): * [1.2.3,0) resolves 1.2.3.v20111010 * [1.2.3.v20111010,) resolves 1.2.3.v20111010 * [1.2.2,0) resolves 1.2.3.v20111010 * [1.2.3-v20111010,) resolves 1.2.3.v20111010 * [1.2.3-v20110909,) resolves 1.2.3.v20111010 * [1.2.3-v20111111,) resolves nothing * [1.2.2,1.2.3) resolves nothing * [1.2.2,1.2.3] resolves 1.2.3 Look pretty much like what I would expect. And that's pretty much unlike the headaches I used to have with Maven dependency resolution...
Oh, I forgot to point out that dash or dot seems to be irrelevant to Maven.
Interesting... I made some other tests with these versions of com.acme.bundle: 1.2.4 and 1.2.4.20111010 (this time without the 'v' in the qualifier). Now, dash and dot *does* make a difference: * [1.2.4.20111111,) resolves nothing * [1.2.4-20111111,) resolves 1.2.4.20111010 I find this last one highly doubtful, but this kind of mixing OSGi and Maven version string syntax should not be the common case. Back to the original patch: I think the version (range) translation is as correct as it can be, and the Maven 3 dependency resolution seems to work with reasonable results.
I tend to agree. The semantics isn't clear at all. In fact they are contradictory. So I'll accept your patch. It's as good as it gets.
(In reply to comment #9) > I tend to agree. The semantics isn't clear at all. In fact they are > contradictory. So I'll accept your patch. It's as good as it gets. @Thomas When/Where can I grab the fixed version?
I'll publish a new version shortly.
Fixed on master with commit http://git.eclipse.org/c/b3/b3.git/commit/?id=fd979a009b40607c5651320c5334dcde6db30a1b
[Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI. No change to assignee for resolved and verified bugs.]
