|Usage of dropins in RCP fails after renaming installation location [message #879569]
||Thu, 31 May 2012 13:00
| Alexander May
Registered: March 2011
after quite a long try-and-error session I finally manged to get dropins working in my RCP product. Basically I do the same as mentioned in forum topic 174347.
Unfortunately dropins do wok only when I run my product from exactly the same location as I exported it to. If I move the installation folder to some other location or even zip and unzip it the dropins support breaks.
I realized when renaming the installation directory just before the first start of the exported product a directory with the old name is created and contains an artifacts.xml and a config.ini file (which both are substantially smaller then the originals).
Why does the application still acces the old directory? It seems as if there where some absolute paths configured. Where can I find/modify them and what parameters do influence creation of artifacts.xml and config.ini?
|Re: Usage of dropins in RCP fails after renaming installation location [message #879811 is a reply to message #879770]
||Thu, 31 May 2012 22:09
| Henrik Lindberg
Registered: July 2009
On 2012-31-05 22:11, Alexander May wrote:|
> Actaully I'm not aware of that issue, although I 'ce found some minor
> hints in other posts.
There are a number of problems with dropins - poor error messages, hard
to update, they lack certain meta-data information etc. etc.
> What is the preferred way installing a single plug-ins? I have several
> user groups that need single functionalities which is already bundled in
> single plug-ins and I want to avoid needing to add a feature for each.
> Is there a better way? It should be as easy as sending the bundle vie
> mail and just droping it somewhere... (just like dropins is)
You can use the p2 director to install things. Your bundles should be
available in a p2 repository either available locally in the file
system, or on an update site (reachable with a http/https/ftp URL).
Things does not have to be features to be installable by p2, that is
just what is shown to the user in the Eclipse UI (users would go crazy
if every bundle was shown all the time).
You need to think about how you keep your users updated as the bundles
you are currently "dropping in" changes / needs to change. When dropping
them in, or installing them as separate roots, it becomes difficult to
support a single update.
Look at how you can publish a p2 site including the bundles, and how you
can use optional and non greedy (i.e. so they are not automatically
installed if present in the repo installing other things from).
There are a lot of powerful things you can do/describe in a p2
repository - the difficulty is often figuring out what you really want
and how to express it.
Hope that helps you searching for more information on topics that can
lead you to a better solution. I am sure someone else must have done
something similar... (not me though, so I can't point you to an example).
Powered by FUDForum
. Page generated in 0.09970 seconds