|How do I update an application without losing customizations in config.ini? [message #929541]
||Mon, 01 October 2012 14:52
| Erik Emanuelsson
Registered: October 2012
We have an RCP app based on Eclipse 3.7 to which we recently added p2-support. It all works fine and we can update the application and install new/update customizations to it just fine via the mechanisms provided by the p2 framework.|
With some extra customizations to the base mechanisms which lets us control update sites + perform install and update operations during application start we have also added optional automatic installation of new features and update of existing features to help our enterprise customers keep their applications up to date. This should allow them to only pack a pure application + some custom settings files once (create a centralized installation package they can push out to users and this is an expensive and time consuming process for them) and then let the update functionality in the application update it to the latest version and install the latest versions of all their customizations automatically.
This all works pretty well apart from one thing. One of our enterprise customers want to use another value for "osgi.instance.area" than the one we ship in our default build. We have this set to a subfolder in "@user.home", but on their clients (Windows XP and Windows 7) this is mapped to a directory that the users have limited quota on so they want it moved to somewhere else.
It is not a problem for them to have the existing config.ini file replaced with a custom one in the version that they pack initially, but when the application is updated it gets overwritten with the default file and hence the value of "osgi.instance.area" is no longer their custom value.
One idea for solving this that I have been pursuing is to generate a new version of a customer specific feature each time we release a new version of our application. The customer could then update both the application and the customization feature at the same time and get their custom value set that way.
I have tried to implement this customization in the form of a simple feature with basically just a "p2.inf" file that replaces the value in "config.ini" with a custom value using the touchpoint "setProgramProperty" like this
This works fine if the customization feature is installed/updated _after_ the application has been updated. If it is installed/updated at the same time as the application itself it has no effect and if we let the application start up with the default value, the standard location is used and we get data written in the directory they do not want to pollute.
I have also tried to use the touchpoint addProgramArg to try to set the "osgi.instance.area" as a program argument instead like this
but even though the argument gets placed into the "myapp.ini"-file, the instance area that is set as a program argument has a lower priority than the one found in the "config.ini"-file and only becomes active if I remove the property from "config.ini".
Does anyone have any tips on how to get a customized "osgi.instance.area" set so it is set and available during the first start of an application after it has been updated?
It is very likely that I do not know enough about p2 and that this limits me in how I approach this problem so any help from you more hardcore p2 users is welcome.
Powered by FUDForum
. Page generated in 0.02549 seconds