|Re: Ensuring a clean bundle cache on multi-user systems [message #717227]
||Fri, 19 August 2011 15:26
Originally posted by: |
On 2011-08-11 11:55, Daniel Krügler wrote:
> I would be interested to know how people solve the problem of
> invalidating the current bundle cache in systems where the default
> configuration area cannot be used (usually because of non-existing
> rights to write into the installation directory of an RCP application,
> e.g. from Windows Vista on) and where multiple users can start the same
> RCP instance. I definitively don't want to start the RCP app with -clean
> each time, but on the other hand starting the RCP with the -install
> -clean parameters for a single time after the installation of a given
> user (typically an administrator), this would only clean the cache of
> the aforementioned administrator.
> A possible solution would be to specify the osgi.configuration.area
> property in the launcher ini file, but how can we ensure that there is a
> directory where all users have read and write rights for? Further this
> would have the effec that the RCP installation program modifies this
> file and this has the effect that the programmer has difficulties to
> test this setting during development time when the RCP app is usually
> started by the Eclipse IDE.
> This problem seems to be rarely discussed but I don't believe that any
> serious nowadays RCP application could exist without solving this problem.
> I would appreciate any hints how to solve this problem properly.
After one week lack of response I must assume that other RCP users must
have defined their own procedures to fix this issue. I cannot believe
that they either use -clean all the time or that they simply have not
noticed this problem yet.
We noticed that defining the configuration area has suddenly unexpected
side effects on the p2 behaviour. E.g. performing a feature install does
no longer add the new plugins to the previous plugin folder. This makes
sense to some extend, and so this is no real cause for a complaint
(except that service people have to be informed about this).
On the other hand it was astonishing to observe that the generated p2
directory is created *parallel* to the provided configuration area
instead of within. Does there exist an additional parameter for an
install invocation that allows the definition of the location of the p2
Thanks in advance,
- Daniel Krügler
Powered by FUDForum
. Page generated in 0.01964 seconds