Blaise,
I have been asked to move OracleDDL to the build version as soon as
is feasible, so it would be changing from 1.0.0 to 2.5.x and be
aligned with the build anyway. Therefore the move now only reflects
the change to come, and the version discovery is simply a stop-gap
for the interim.
Antlr and asm are special cases, similar to bundles based upon a API
spec, like javax.persistence 1.0/2.0/2.1 or commonj.sdo 2.1.0/2.1.1.
They are versioned based upon the non-OSGi library the source is
from, and as I understand it we are not allowed to modify the source
other than altering the package hierarchy. Any fixes would be to
Manifest, or text content. Therefore we moved to versioning the
bundles with the same three-part version as the original to better
reflect the version of the library we use. We cannot increment this
version without destroying the linkage. Incidentally, moving back to
building it every night would have the same net result, and not have
the benefit of the linkage.
However, I believe revving these jars is only slightly more
likely than revving commonj. The jars have been viable and static
for several releases. The need to rev them would most likely come
from changing the version of the source along with the content
(though at that point several iterations may be needed to stabilize
the bundle).
We could move to a completely independent versioning scheme for
these bundles and simply specify the original library version in a
manifest entry like "Spec-version: ___", however as this is much
less obvious it was voted down originally.
We could also change the versioning such that the initial or
secondary number be a concatination of the library version: 1.320.0
or 320.0.0 for ANTRL and 1.331.0 or 331.0.0 for ASM to both reflect
linkage and retain the ability to increment.
Another option would be to keep them publishing separate for space
considerations and move the the existing 3-part version, then if we
need to increment we could adopt a new versioning standard as
outlined above - though that seems pretty clunky and potentially
confusing to me.
At this point, the benefit of changing versioning schemes would
be slight and churn could potentially be pretty high. I'm uncertain
if there would be sufficient benefit, though perhaps a savings of
roughly 900kb per build (stored in the .m2) may be worth
considering.
If we want to take up the issue again, I'm open to it.
Eric
On 01/02/2013 11:38 AM, Blaise Doughan wrote:
Hi Eric,
antlr, asm, and oracleddl will publish under the build
version and not their own unique version anymore
(this will take more space but more importantly it will
not end up violating the "once published
never changes" rule since stripping the qualifier
wouldn't give a unique version)
If they needed to change wouldn't we just bump the version then?
-Blaise
On 13-02-01 11:31 AM, Eric Gwin wrote:
All,
For the Maven Central work, I'm having to realign some of our
coordinates for publishing to Maven:
antlr, asm, and oracleddl will publish under the build version
and not their own unique version anymore
(this will take more space but more importantly it will not
end up violating the "once published
never changes" rule since stripping the qualifier wouldn't
give a unique version)
commonj.sdo will now publish under o.e.p groupId
javax.persistence and commonj.sdo will use only the three-part
version (qualifier stripped)
(commonj is a risk, but Blaise and David concur and are
willing to bump to 2.1.2 if a
rev is needed).
I'm also going to be testing the javadoc linkage today, and if
it goes well will be activating the
SonatypeOSS push for tonight as well. Hopefully this weekend
will yield a potential M7 candidate.
The big question is whether or not to make these changes to 2.4
as well. I think we have to, and don't
think it affects our status with the Eclipse Release train at
all (both because Maven isn't part of the
release train criteria, and 2.4.2 isn't in it). Also due to our
dependency publishing it shouldn't effect
users at all (unless they were explicitly pulling components in
question).
Regardless these changes would need to be applied to any release
we were going to push to Maven Central
anyway, and I think it makes sense to align our Eclipse repo to
the new coords as well (for as long as it
is in existence).
Any thoughts?
Eric
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
|