> because I'd like confirmation that Orbit bundles follow a versioning > standard where the bundle uses the version of the original jar > followed by the build date: > javax.foo.jar (version 1.0.3) -> javax.foo_1.0.3.<date/time built>.jar
I see I never answered you main question, so will now confirm, yes, that's pretty much it. The first three segments are meant to match exactly the original 3rd party jar/bundle, but the qualifier is not literally "date/time built" but rather "date/time of last CVS change", just to be explicit. HTH From: David M Williams/Raleigh/IBM@IBMUS To: Cross project issues <[email protected]>, Date: 01/03/2012 03:07 PM Subject: Re: [cross-project-issues-dev] Orbit and Maven question... Sent by: [email protected] Yes, I am still lead, and no, no "eclipse-maven" coordination about versioning that I am aware of. There is some ongoing discussion of maven-orbit issues in bug 364469 [1] and elsewhere, but first I've heard of "versioning issues". The problem of OSGi and Maven treating 3 part versions opposite of each other sounds like a whopper. You might already know the answer, but a broader question might be if OSGi and Maven have tried to "coordinate" anything about versioning, which could be asked on OSGi mailing list, [email protected] . As an aside, Orbit specific questions can be asked on "[email protected]". As another aside, the info pages produced by the Eclipse Foundation should always be accurate in terms of "leads", etc., see http://www.eclipse.org/projects/listofprojects.php or for orbit specifically, http://www.eclipse.org/projects/project.php?id=tools.orbit Thanks, sounds like some important issues between "communities" and nice to know someone is working on them. I'm sure many in Eclipse will be interested in your progress or outcome. [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=364469 From: Eric Gwin <[email protected]> To: David M Williams/Raleigh/IBM@IBMUS, Cross project issues <[email protected]>, Date: 01/03/2012 02:15 PM Subject: [cross-project-issues-dev] Orbit and Maven question... Sent by: [email protected] David, You are listed as the lead for Orbit, but the project pages don't appear to have been updated for a while. I'm wondering if you are still the lead, because I'd like confirmation that Orbit bundles follow a versioning standard where the bundle uses the version of the original jar followed by the build date: javax.foo.jar (version 1.0.3) -> javax.foo_1.0.3.<date/time built>.jar My understanding is that this is the case, and that it is followed to easily track the jar that is wrapped (1.0.3), and maintain the ability to fix wrapping bugs (by changing the qualifier:1.0.3.x). The reason I'm asking is that our team publishes a maven repository for our artifacts, and has for years. A few years ago we added our run-time dependencies (which come from orbit). At the time there was no coordinated effort to support Maven at Eclipse, and we were fairly new to Maven as well. Since Orbit could release many updated versions of the same bundle: javax.foo:1.0.3.x javax.foo:1.0.3.y javax.foo:1.0.3.z We had a problem. Maven standards recognize only a three-part version and qualifier, but there are special rules, so in order to maintain the immutability of a "version" (javax.foo:1.0.3.x) we had to publish Orbit bundles using the qualifier as well. However, opposite of OSGi standards, with Maven a three-part version alone (1.0.3) is always higher than three-part version and qualifier (1.0.3-x) {That meant that 1.0.3 would always supersede 1.0.3-<anything>}. In an attempt to eliminate confusion between versions, we normalized using the four-part Orbit version (1.0.3.x), so we could publish updated Orbit bundles. A side-effect in Maven is that indexing won't work. I'm wondering if you are aware of any standards Eclipse has adopted for Orbit bundles with the Mavenization projects. We've been asked to migrate to the Eclipse Maven repository, and I want to be sure I don't duplicate effort, and curious at the solution they reached. -Eric _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
