|Re: [eclipselink-dev] EclipseLink OSGi manifest exports...
You are not wrong. I was only talking about changing the export. As far as Require-bundle taking care of any internal api changes, didn't we reduce the range specification to 2-part to allow for the case where a bugfix to jpa doesn't have to include a new core, which could in-turn affect MOXY, forcing a new bundle there as well? Yesterday I was looking at the problem from a "reduce maintenance" perspective. Now I'm leaning more toward the "if it ain't broke, don't fix ('cuz you might just break it)" end of the spectrum. I cannot think of a scenario where reducing to just a 2-part export version actually helps (except not needing to up the 3rd part at the beginning of every patch release cycle), however it may be possible to get into a situation where 3-parts might be needed. -Eric On 25/11/2011 8:21 AM, Tom Ware wrote:
Hi Eric, My understanding was that we were always keeping the 3 part version for the Bundle version and that we were only changing to a two part version for the package exports. Am I wrong? In that case, the internal dependencies are currently satisfied using Require-Bundle and not package imports - and hence would use the 3 part version anyway. -Tom On 25/11/2011 7:16 AM, Eric Gwin wrote:I just thought of something... We do change "internal API" during patch releases releases (2.3.2, 2.4.1). If it were to change, core and jpa, or core and moxy, would end up requiring a dependency on a patch release to fulfill an internal API contract. While in most cases we probably don't need the three part version in the export, I think we may in those cases. Therefore, I'm going to reverse myself, and keep the three part version in the export. It won't hurt to keep it, we may need it, and I don't want to have to go back and fix it. I'll just remove the qualifier. -Eric On 24/11/2011 2:42 PM, Eric Gwin wrote:Hi, Tycho won't do qualifier substitution on any part of the manifest except the bundle-version when building manifest-first. We currently export eclipselink packages using "2.4.0.qualifier" in 2.4. Most eclipse teams simply export using "Major. minor" versions. This seemed imprecise but upon further discussion of the OSGi spec, and how the class/bundle loading works it now appears most concise. Major.minor are the only portions of the three part version that should be used to specify API contract compatibility. Specifying the full three part version is overkill, and should be unnecessary since bundle version (fully four part specified) is used to determine version "age". As a result, I'm proposing altering all our manifests to both import and export based only upon "Major.minor" versions and to eliminate non-OSGi tags that specify .qualifier. If you can think of any reason not to do this let me know ASAP. At a minimum I need to remove the exporting of .qualifier. Thanks. -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_______________________________________________ eclipselink-dev mailing list eclipselink-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
Back to the top