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
|
