IMHO, coming up with general rules is going to be close to impossible. Instead, we should make this configuration explicit, I.e. Have a configuration on the installer which declares the action per BSN.
Justin On Mon, Sep 21, 2015 at 1:26 PM Carsten Ziegeler <[email protected]> wrote: > Unfortunately, the OSGi installer does not support this use case, and > the same goes with the web console from Apache Felix. > > Actually, this feature has been requested several times, but so far we > never did anything. I think the easiest way would be to make the > distinction based on the major version: > - same major version -> update > - different major version -> install > > If that behaviour is not sufficient, we can think about further > controlling it. While the OSGi installer has the ability to get passed > additional parameters for an artifact, which could be used to further > control this behaviour, the problem is how to specify this? When > artifacts are installed from the file system there is basically no nice > way to do this. For the JCR repository, properties could maybe add > somewhere? > > Carsten > > Am 21.09.15 um 19:01 schrieb Steven Walters: > > On Mon, Sep 21, 2015 at 12:05 PM, Jason Bailey <[email protected]> > wrote: > > > >> I'm a bit confused by the use case. > >> > >> Breakage should only occur if the bundle is exporting an API that is > >> versioned, and you have a bundle that is explicitly set to not accept > the > >> new package version. > >> > >> Or is the breakage somewhere else? > >> > > > > Continuing on the example here for google's guava, guava-17.0.jar exports > > its packages with versions of "17.0.0" > > With commonly used tools such as bnd, by utilizing one of these packages > > (let's say the "com.google.common.io" package for driving the example), > the > > resulting manifest (by default) will have an import package declaration > of ' > > com.google.common.io; version="[17.0,18)"' > > This is due to the expectation of practical semantic versioning. > > > > In guava-18.0.jar, the packages are exported with versions of "18.0.0" > > So in this scenario where guava 17 is "updated" to 18 within OSGi > (instead > > of 18 appearing as a new bundle), such bundles will now fail to > > wire/resolve due to 'com.google.common.io; version="[17,18)"' now no > longer > > being available within the system. > > > > Yes, the import declaration can be specifically set when building to > > something such as "[17.0, 19)", but not only does this start opening > > unnecessary risk (is there any real guarantee 18 will work?), > > this workaround really only applies to the bundles we control (create) > > ourselves. That is, this workaround can not be particularly applied to > > already existing (other 3rd party) bundles. > > > > > > An "updating-only" paradigm primarily defeats one of the key points of > OSGi > > where multiple versions of the same packages are meant to be able to > > simultaneously exist "in harmony". > > Felix does support properly support the scenario of having multiple > > versions of the same packages, though so far I've only been able to > achieve > > it so far within the gogo shell (the Web Console does not support this > > scenario properly yet it seems from the looks of FELIX-4142). > > > > So primarily looking for clarification if the JcrInstaller can support > this > > (through the underlying OsgiInstaller framework Sling has), and how to > > utilize this functionality if it does. > > > > -Steven > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] >
