[EMAIL PROTECTED] 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. Th
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 der
I'm not sure I understand this ...
Simple configurator has two lists 1) a list of bundles it thinks need to be
uninstalled 2) a list of bundles it thinks it need to be installed.
Right now the configurator uninstalls all the bundles in uninstallList and
then installs all the bundles in installLi
In fact I don't know of any management agent capable of calling update in
the way a user could do on the command line since the definition of update
support updating any bundle into any other...
In p2 we have explored solutions to this problem and were able to come up
with a solution for the trivia
Another issue here is how bundles are updated to new versions. The CM
implementation uses the BundleContext.getDataFile method to obtain a
location to persistently store its data. This data area is unique to the
Bundle ID (long value). When a bundle is updated (using Bundle.update
method) the u
Glad it's working now...
You're point about compatability of the store data is really interesting (I
think so at least).
In terms of technical details as part of the graduation work we switched
from using regular files to the frameworks ReliableFile infrastructure.
This does change the layout on d
