Home » Eclipse Projects » Equinox » RCP app can't see plug-ins installed in separate configuration area
| RCP app can't see plug-ins installed in separate configuration area [message #1062778]
||Mon, 10 June 2013 13:15
| Klara Ward
Registered: July 2009
I have an RCP app (based on Eclipse 3.8.2)|
which will be installed in c:\Program Files\..... by default on Windows.
So to be able to install plug-ins in my app, I need to set osgi.configuration.area to somewhere writable.
The problem is that when I install plug-ins, and restart my app, I can only see the newly installed features, but not the newly installed plug-ins, and the functionality they provide does not work..
I compared with an installation of Eclipse where I also installed my RCP app base plug-ins. Then I set osgi.configuration.area for Eclipse as well, and installed the same "extra" plug-ins that I install in my RCP app.
In this case, it worked fine, I can see the plug-ins, and they work as well.
What are the files that are most relevant to what plug-ins are actually loaded?
What Eclipse code do I debug?
I tried to compare the two config areas (RCP app and Eclipse), and the simpleconfigurator/bundles.info seems to differ quite a bit, for RCP app it's only two lines, for Eclipse it's the full set of installed plug-ins.
I've seen numerous questions in this area on forums, and also a number of Eclipse bugs, most of them seem closed. Non of the fixes/workarounds seem to work for me.
This is the config.ini I started out with:
This is the config.ini after switching to using a bundles.info file and adapting some of the other things from the Eclipse config.ini:
|Re: RCP app can't see plug-ins installed in separate configuration area [message #1064222 is a reply to message #1063875]
||Tue, 18 June 2013 06:29
| Markus Persson
Registered: July 2009
Pascal, thanks for the help. We (Klara and I) have now resolved this issue.|
The reason was that we provided the wrong IU to the p2 Director. Instead of specifying the IU of the product itself, we had accidentally specified the IU of the containing feature.
Since this feature was the entire contents of the ".product", everything seemed to work anyway. (Due to being part of a larger install, the binary launcher was handled separately,
outside of the "eclipse" directory, and the config.ini inserted afterwards.)
But of course, what was missing was the CUs, in particular "tooling.osgi.bundle.default". (Since the update site in question was a pure add-on repository, p2 Publisher hadn't
added that CU in there either.)
In the non-shared install scenario, installing from the update site did "work" since we still have the legacy "org.eclipse.update.configurator" bundle (since the pre-p2 days),
which AFAIK simply adds any bundles it finds in the sites specified in platform.xml to the OSGi runtime. Am I correct in assuming that we could and should remove
"org.eclipse.update.configurator" from our product altogether?
For reference, our issue (and solution, I guess) was very similar to the one described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=241559 .
Current Time: Thu Dec 05 04:49:10 EST 2013
Powered by FUDForum
. Page generated in 0.01915 seconds