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