| Re: [equinox-dev] [prov] install / uninstall / update (was Configuration Admin bug) |
equinox-dev-bounces@xxxxxxxxxxx wrote on 12/07/2007 12:18:09 PM:
> The bundle.getLocation() does not matter, but since so many systems are
> used around that it is also problematic to not having meaningful.
>
> For clarification to the casual reader, simple configurator does not
> explicitly have two lists. The lists of things to install and to uninstall
> are actually derived by analysing what is in the system and what the system
> should look like.
>
> Now for the corner cases (in each case the bundles.txt described lists all
> the bundles):
>
> Example 1:
> In the system: Let's say that I have junit 3.8.1 and junit 4.1 installed
> (boths are singleton)
> case 1) In the bundles.txt: I have junit 5.0 - Do I update the two bundles
> ? Do I update the highest one or the lowest one, why?
> case 2) In the bundles.txt I have junit 3.8.2 - Is it an update or a
> donwgrade?
> case 3) In the bundles.txt I have junit 3.8.4 and junit 4.0 - Which one is
> really an update?
>
>
> Example 2:
> In the system: Let's say that I have foo 1.0.0 (it is singleton)
> case 1) In the bundles.txt I have foo 1.1 and foo 1.2 (these are no longer
> singleton) - Which bundle do I pick to be an update of the one present?
>
>
> Example 3:
> In the system: Let's say that I have bar 1.0.0 and bar 2.0.0 (both are non
> singleton)
> case 1) In the bundles.txt I have bar 1.5 (singleton). - Which one do you
> update? Why?
We may be able to rationalize some policy for the above cases but since this
is a "simple" configurator that is likely out of the question because it
will get complicated fast ;-)
So I punt on this and say if multiple versions of the same bundle are in
the scenario then just do the uninstall(old) install(new) versions
approach. In most cases where multiple versions are needed the bundle
is not a singleton and is just a library. In this case it should not
matter if you uninstall/install the bundle to be updated.
In cases where the system should only have one version of the bundle
installed it seems like you could use the update approach instead.
>
> The other problem with updates, is that given two systems starting from the
> same initial state, if they are submitted to different bundles.txt over
> time to finally get to the same one. Even though the resulting systems look
> the same it is not clear that they will actually behave the same depending
> on what the data file may contain.
> Another one in that space is, someone starting fresh and someone applying a
> bundles.txt over a system may not end up with the same runtime behavior (of
> course bundles should all be written properly, etc.... but you know the
> truth :-))
>
> PaScaL
Not sure what the answer is to this one. Bundles have bugs in them but should
we throw away the update capability because some bundles cannot handle managing
their persistent data correctly? I do not see how this is different from the
other data bundles store in the configuration.area. Generally this type of
data should be versioned so that when new versions are installed they can
determine if they understand the data or not.
This is also another option for the CM implementation. It could persist its
data in the configuration.area. This area is not tied to the bundle ID or
location. The drawback to this approach is that only one version of CM
can manipulate this data. This is probably not an issue though since CM
should probably be a singleton bundle anyway. This is essentially how
the Eclipse preferences bundle persists its data.
Tom