Plugins Stopped Working After Upgrade To Maverick

Hi

In Debian we have been experiencing problems with the simpleconfigurator, which I hope we can solve by improving the simpleconfigurator and its handling of read-only shared installs.

The situation:
In Debian (and Ubuntu) we distribute eclipse via our own package format using eclipse-build from LinuxTools. In our eclipse-platform package we ship the basic part of eclipse (e.g. without -jdt or -pde) and this contains a bundles.info. This contains information about all bundles eclipse depends on as well as the bundles we ship in eclipse-jdt and eclipse-pde (these two may or may not be installed on the system).
  When the user starts eclipse for the first time, eclipse will generate a bundles.info file in his/her home directory inside ~/.eclipse/ somewhere. So far so good.

The problem:
If we (for whatever reason) need to upgrade an external bundle (say our lucene2 bundles), the bundles.info files are outdated. We can (from the distributing side) ensure that the system bundles.info always are in sync with the bundles installed on the system in the shared install, but we cannot update the bundles.info in the user's home directory.
  The symptom is that all the user installed bundles are silently dropped and only the bundles provided in the system bundles.info are present. This seems to be confirmed by the code in SimpleConfiguratorImpl.java (line 103 in eclipse 3.6.2):

   return (userBundles.containsAll(sharedBundles)) ? userConfigURL : sharedConfigURL;

As you can probably imagine this is first of all very hard to debug and secondly suboptimal for us and our users.

My proposal is to extend the simpleconfigurator to handle this case by never storing system bundle info in the user bundles.info file and always load the bundles from the shared install's bundles.info.
  Obviously, just naively doing that may break existing installs, so I am perfectly okay with us having to explicitly setting a property in the config.ini or use a variant of the bundles.info.

I understand that your time may be limited and you may have tasks with higher priority, so I am willing to assist with the changes (though my knowledge in this area is somewhat limited).

If this is implemented, we would like to backport it to our eclipse 3.7 (or 3.7.X) package, so it would be greatly appreciated if patches could be posted here.

Thanks for considering and your time,
~Niels

I strongly support that.

Stay tuned, more actions to follow. DJ will be sending emails on the p2-dev ml (https://dev.eclipse.org/mailman/listinfo/p2-dev) to capture the requirements on shared installs, and we can then discuss the appropriate solution (I'm not a fan of editing files like done here).

Also now that someone from Redhat has expressed similar interest a couple weeks ago, so it definitely looks like the stars are lining up for something good to be done here.

Sorry for the delay responding.

I've opened bug 358471 as an umbrella work item to keep track of things we want to look at for the Juno release. If you have other issues which you feel might fall under the general "improve shared install support" theme then feel free to open a bug report and mark it as a blocker of bug 358471.

As for discussions I believe it makes sense to carry them out in the individual bug reports themselves, so they can remain focused on a particular aspect. I may open another bug report to discuss some of the overall ideas that Pascal was alluding to.