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]
