Hi,
I'm writing this to get a discussion going (and maybe even a policy) on the
right thing to do when Bundle-SymbolicNames might change.
Generally when a newer version of a bundle is added to Orbit, the old one
one is still around, and the Bundle-SymbolicName remains unchanged.
Consumers whose range of requirements include the new version would begin
pulling that one. As we start using orbit-recipes, to continue updating
bundles, the default Bundle-SymbolicName used will be a combination of the
groupId and artifactId of the bundle within Maven Central, which might not
be what was used previously.
As an example, we ship Bouncy Castle Provider 1.51 with a BSN of
'org.bouncycastle.bcprov' in Orbit, but in orbit-recipes, 1.52 it is
'org.bouncycastle.bcprov-jdk15on'. Even with more lax retention policies
that mandate only mainting one version (and assuming no one cares about the
older one), should changing the BSN like this be allowed ?
The problem with this is that projects are no longer guaranteed to get the
highest version of a dependency that satisfies their requirements because
that functionality in p2 resolution is done for bundles that have the same
BSN. It's simple enough for them to be specific about what they want in
their target platforms but should we be forcing this on projects whereas
before things would work without any changes ?
So if there's nothing objectionable about a BSN used for a bundle from
the old Orbit repo, should we just commit to keeping the same name ?
Cheers,
--
Roland Grunberg
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/orbit-dev
