Eclipse

Plugins Stopped Working After Upgrade To Maverick

Bug #633198 reported by Vincent Xue on 2010-09-08

This bug affects 15 people

	Status	Importance	Assigned to
Eclipse	Confirmed	Wishlist	eclipse-bugs #351485
eclipse (Debian)	Fix Released	Unknown	debbugs #587657
eclipse (Ubuntu)	Triaged	Medium	Unassigned

Bug Description

Binary package hint: eclipse

Description: Ubuntu maverick (development branch)
Release: 10.10

eclipse:
  Installed: 3.5.2-6
  Candidate: 3.5.2-6
  Version table:
*** 3.5.2-6 0
        500 http://us.archive.ubuntu.com/ubuntu/ maverick/universe amd64 Packages
        100 /var/lib/dpkg/status

The plugins for Eclipse have stopped working after I upgraded to maverick. I have tried reinstalling eclipse and the respected plugins without any luck.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: eclipse 3.5.2-6
ProcVersionSignature: Ubuntu 2.6.32-24.42-generic 2.6.32.15+drm33.5
Uname: Linux 2.6.32-24-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Wed Sep 8 09:40:34 2010
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
PackageArchitecture: all
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: eclipse
xulrunner-versions: /usr/lib/xulrunner-1.9.2.9

Tags:

Revision history for this message

Vincent Xue (xuevin) wrote on 2010-09-08:

Dependencies.txt Edit (4.5 KiB, text/plain; charset="utf-8")

Revision history for this message

Niels Thykier (niels-thykier) wrote on 2010-09-08:

I strongly suspect that you are suffering from http://bugs.debian.org/587657 - your user level bundles.info is outdated and eclipse fails to fix it. I cannot guarantee there will be an automated fix for this in the Maverick release cycle - I still have been unable to figure out if this is a missing regression or a missing feature in eclipse.

To fix it you can either update it manually (see the debian bug for more info on this) or remove ~/.eclipse and reinstall your plugins. Hopefully future releases of eclipse in Debian and Ubuntu will feature some mechanism to do this automatically.

Please note that first time users of eclipse installing the latest version of eclipse are unaffected by this. Only users upgrading eclipse can be affected by this particular issue.

~Niels

Changed in eclipse (Ubuntu):
status:	New → Confirmed

Revision history for this message

Vincent Xue (xuevin) wrote on 2010-09-09:

Hi Niels,

Thank you for your help! The solution you provided has solved my problem. I hope that you can find an automated way to fix this problem in the future.

Cheers,
Vincent

Bug Watch Updater (bug-watch-updater) on 2010-10-12

Changed in eclipse (Debian):
status:	Unknown → New

Revision history for this message

Thibaut Robert (thibaut-robert) wrote on 2010-10-29:

Hi,

The solution from http://bugs.debian.org/587657 also solved the problem for me.

Regards,
Thibaut

Revision history for this message

Henri Sivonen (hsivonen) wrote on 2010-11-09:

> To fix it you can either update it manually (see the debian bug for more info on this)

The sed recipe didn't work for me. Were you referring to something else?

Revision history for this message

Niels Thykier (niels-thykier) wrote on 2010-11-26:

@Henri Sivonen

Hey, sorry for the late reply.

The sed recipe looks like it will work in the "average" case, but unfortunately not every case as you experienced. The "full" solution, which I referred to in the Debian bug #587657, is to manually "merge" the two bundles info files.
The user level bundles info will contain an outdated version of the system bundles info plus information for all the plugins you have installed yourself as a user (namely all the plugins you are missing). Updating the outdated information in the user level bundles info appears to fix the issue.

~Niels

Revision history for this message

Niels Thykier (niels-thykier) wrote on 2011-02-01:

Hey,

Someone with sufficient permissions; please mark this as Triaged and Priority Medium (or even High).

~Niels

Benjamin Drung (bdrung) on 2011-02-01

Changed in eclipse (Ubuntu):
status:	Confirmed → Triaged
importance:	Undecided → Medium

Revision history for this message

In Eclipse bugs #351485, Niels Thykier (niels-thykier) wrote on 2011-07-07:

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

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

Revision history for this message

Redsandro (redsandro) wrote on 2011-07-20:

Confirmed after upgrade from Ubuntu 10.04 LTS to Linux Mint 11 (essentially Ubuntu 11.04 without the retarded interface)

Bug Watch Updater (bug-watch-updater) on 2011-08-10

Changed in eclipse (Debian):
status:	New → Confirmed

Revision history for this message

In Eclipse bugs #351485, Nikolaus Rath (nikratio) wrote on 2011-08-11:

#10

I strongly support that.

Revision history for this message

In Eclipse bugs #351485, Pascal-57 (pascal-57) wrote on 2011-09-22:

#11

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.

Revision history for this message

In Eclipse bugs #351485, Dj-houghton (dj-houghton) wrote on 2011-09-22:

#12

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.

Bug Watch Updater (bug-watch-updater) on 2012-05-20