Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Orbit and Maven question...

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,
osgi-dev@xxxxxxxxxxxxx .

As an aside, Orbit specific questions can be asked on
"orbit-dev@xxxxxxxxxxx".
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 <eric.gwin@xxxxxxxxxx>
To:	David M Williams/Raleigh/IBM@IBMUS, Cross project issues
            <cross-project-issues-dev@xxxxxxxxxxx>,
Date:	01/03/2012 02:15 PM
Subject:	[cross-project-issues-dev] Orbit and Maven question...
Sent by:	cross-project-issues-dev-bounces@xxxxxxxxxxx



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
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev





Back to the top