Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 322056

Summary: Shared install local plugins not loaded due to mishandling of bundles.info
Product: [Eclipse Project] Equinox Reporter: Ben Tels <bzt>
Component: p2Assignee: P2 Inbox <equinox.p2-inbox>
Status: CLOSED DUPLICATE QA Contact:
Severity: major    
Priority: P3 CC: bzt, irbull, niels, simon_kaegi
Version: 3.6   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard:
Attachments:
Description Flags
bundles.info -- local file
none
Shared bundles.info none

Description Ben Tels CLA 2010-08-07 14:58:46 EDT 
Build Identifier: 20100617-1415

I'm working on Linux (OpenSuSE 11.3, just to be complete) and am doing a shared installation of Eclipse 3.6/Helios (i.e. read-only installation of Eclipse in /opt owned by root, with automatically created ~/.eclipse and so on per user).

When installing plugins as a regular user (either using the marketplace or "Install New Software"), the plugin(s) install(s) correctly, but are not loaded when Eclipse restarts. So far the problem is the same as described in bug 297329 (towards the end).

Analysis of the installation shows the following:

* The bundles.info in the shared install remains unchanged, which seems correct.
* The bundles.info in the user's config dir is a combination of the shared install one and the newly registered plugins, which are located in the local plugins directory (~/.eclipse/.../plugins); however the location of the local plugins is referred to RELATIVE TO THE SHARED INSTALL DIRECTORY and not relative to the user's config dir.

The situation as described above could be correct, if Eclipse were to use the user's local bundles.info relative to its shared install location. However, it persists in using the shared copy. I have verified this by temporarily replacing the shared location bundles.info with a symlink to the file in the user's config directory; with that change, the plugins are loaded correctly (for that user, obviously). Although in this configuration the user cannot install any more plugins (leads to failure).

I've tried experimenting with different settings for osgi.configuration.cascaded, osgi.sharedConfiguration.area and org.eclipse.equinox.simpleconfigurator.configUrl, both in the local and in the shared config.ini, in an attempt to come up with a permanent and multi-user analog to the symlink. However, nothing results in a working solution (the configuration described above stays in effect until I clear the cache using "-clear", then the new configuration kicks in and causes a boot-time error in Eclipse).

In any case, the base problem seems to be that Eclipse is ignoring the local bundles.info in a shared installation. As a result, the shared install is broken in Helios.

Reproducible: Always

Steps to Reproduce:
1. Create a read-only installation of Eclipse.
2. Start Eclipse as a regular user to create a local config.
3. As that user, install one or more plugins.
4. Allow Eclipse to restart the workbench.
5. The plugins are now visible in the plugin installation history, but not loaded or active. The bundles.info files are in the state described above.
Comment 1 Simon Kaegi CLA 2010-08-07 23:07:18 EDT 
What are using as your base install. e.g. which EPP package from the download page.

If the users bundle.info does not contain a reference to every bundle in the shared bundle.info the shared bundle.info is used as the basis of the install. If possible could you compare the two to see if you can see any difference.
Comment 2 Ben Tels CLA 2010-08-08 05:54:20 EDT 
(In reply to comment #1)

Hi Simon,

> What are using as your base install. e.g. which EPP package from the download
> page.

The basic Eclipse IDE for Java Developers package. Which I downloaded explicitly to experiment with, but I had an earlier experience with exactly the same problem on the package for JEE development (which is currently installed per-user due to this problem).

> If the users bundle.info does not contain a reference to every bundle in the
> shared bundle.info the shared bundle.info is used as the basis of the install.
> If possible could you compare the two to see if you can see any difference.

I just did a diff of the two. The local file is a strict superset of the shared file (i.e. it has lines that are not in the shared file, but the entire contents of the shared file are in the local file).

Does Eclipse use a diff-like tool to compare local and shared files? Because I did notice the extra lines in the local file are mixed in with the lines that were copied over from the shared install. If Eclipse is using a diff-like algorithm, could the existence of differences in the middle of the file be leading to make the wrong choice?
Comment 3 Ian Bull CLA 2010-08-09 14:12:36 EDT 
(In reply to comment #2)
> 
> I just did a diff of the two. The local file is a strict superset of the shared
> file (i.e. it has lines that are not in the shared file, but the entire
> contents of the shared file are in the local file).
> 
Hum.. I've reproduced a similar problem on Linux, but in my case the Shared file was not a strict subset of the Local file (some entries from the shared file have been removed / changed).

> Does Eclipse use a diff-like tool to compare local and shared files? Because I
> did notice the extra lines in the local file are mixed in with the lines that
> were copied over from the shared install. If Eclipse is using a diff-like
> algorithm, could the existence of differences in the middle of the file be
> leading to make the wrong choice?

IIRC, Eclipse just loads the contents into two sets and does some set math.  So the fact that they are mixed shouldn't cause a problem.

Can you upload the two bundles.info files?  It would be interesting to see if there is anything else in there that could be causing problems.

FWIW, I do have shared installs working (there is appears to be some combination of installs that lead to this).  When it works, I also have the local plugins referenced relative to the shared install directory, and this appears to work fine.
Comment 4 Ben Tels CLA 2010-08-12 14:28:07 EDT 
Created attachment 176489 [details]
bundles.info -- local file

The locally installed file with the local plugin references.
Comment 5 Ben Tels CLA 2010-08-12 14:29:10 EDT 
Created attachment 176490 [details]
Shared bundles.info
Comment 6 Ben Tels CLA 2010-08-12 14:30:47 EDT 
(In reply to comment #3)
> Can you upload the two bundles.info files?  It would be interesting to see if
> there is anything else in there that could be causing problems.

I've uploaded them. Sorry for the delay -- I didn't get a mail of your reply for some reason.
Comment 7 Ian Bull CLA 2010-08-12 14:45:49 EDT 
Ok, I'm pretty sure this is the same issue that we've seen time and time again. I need to start closing these as duplicates so we can keep all the information in one place.

In this case you do have all the bundles in your local bundles.info file, but some of them have 'moved' from your shared to your local area. BundleInfo objects are compared with location, so this change makes them not equal.

Thanks for uploading these files.

Just so you know, this appears to be a configuration problem with the EPP packages (that's the root cause).  I'm working with them to see if we can get that configuration problem fixed.  

Thanks again!
Comment 8 Ben Tels CLA 2010-08-12 15:45:08 EDT 
(In reply to comment #7)
> Just so you know, this appears to be a configuration problem with the EPP
> packages (that's the root cause).  I'm working with them to see if we can get
> that configuration problem fixed.  
> 
> Thanks again!

No problem. Hope it helps you guys to get it fixed!

Thanks, 

Ben.
Comment 9 Ian Bull CLA 2010-09-14 02:05:16 EDT 

*** This bug has been marked as a duplicate of bug 322929 ***