On Mon, Sep 21, 2015 at 1:26 PM, Carsten Ziegeler <cziege...@apache.org> 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 > I think the suggested change to the default behavior makes sense. Granted there are some scenarios where I could see this being rather complicated such as if a bundle had a minor version bump but incremented its package by a major version, such as a bundle incrementing from "2.0" to "2.1", but package X increments from "2.0" to "3.0" (I do hope there is no one actually doing this in practice however). > > 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 > As for further control or refinement, which can be useful for more particular scenarios or possibly for particular vendor desired behaviorisms (Adobe perhaps for AEM surrounding their Hotfix and SP system, which may be useful for their existing "fileinstallpatch" installer) for the JCR side, properties could be on the watched folder or on the nt:files to indicate the behavior of what should happen to bundles if needing to override the default. For the file system side, this can either be either by altering the sling.fileinstall.dir property behavior some. the property already accepts commas for lists of paths, so extending the grammar a bit more to allow an extra delimiter such as : or ; to indicate the override mode to apply for that folder, such as /sling/watch/folder/a:install,/sling/watch/folder/b:update,/sling/watch/folder/c Or there could be some particular file (whether purely by name, or by a name and defined by its contents) within the watch folders that refine the behaviorisms, and this could work for both JCR and file system modes. Such a behavioral change does open up some interesting scenarios though, such as the following 1) "Gap version update" Prerequisites: Bundle "X" is within folder "foo" at version "5.0" Folder "foo" is set to always update, Bundle "X" is also installed at folder "bar" at version "7.0" Folder "bar" is set to default behavior Steps: Bundle "X" at version "6.0" is placed into folder "foo" Possible expectation: Bundle "X" at "5.0" is updated to "6.0" Such an expectation seems reasonable, at least to me. 2) "Update to already existing major version, though of a higher minor" Prerequisites: Same as above Steps: Bundle "X" at version "7.1" is placed into folder "foo" Possible expectations: a) Bundle "X" at "5.0" is updated to "7.1" b) Bundle "X" at "7.0" (within "bar") is updated to "7.1" c) Unable to decide which to update -> do nothing. Here, the interesting choice is which bundle would get the update: the one in the same folder, or the one that matched the major version? Either routes have their merits, but which should it be? That is, what would be the "matching algorithm" be for existing bundles to be updated? Route "a" takes an approach of "same folder as existing bundle so it should update any bundle in its own co-located folder first, before updating 'outside' bundles" Route "b" is more along the lines of "select any bundle matching same major version, before matching against other versions" Route "c" is always a valid option, and may be a route to go down for a while until a more discussed and agreed upon solution arises for such a scenario. -Steven
