| Re: [eclipselink-dev] Changes for MavenCentral... |
|
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, |