Bug 458626 - Eclipse sometimes fails to pick up fragment plugins from /usr/share/dropins
Eclipse sometimes fails to pick up fragment plugins from /usr/share/dropins
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
10
All Linux
medium Severity high
: ---
: ---
Assigned To: Alexander Kurtakov
Fedora Extras Quality Assurance
: Triaged
: 468714 480557 514077 (view as bug list)
Depends On:
Blocks: 444937
  Show dependency treegraph
 
Reported: 2008-08-11 03:18 EDT by Sean Flanigan
Modified: 2009-12-18 01:17 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:17:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
RPM containing French translations as plugin fragments (2.23 MB, application/octet-stream)
2008-08-11 03:18 EDT, Sean Flanigan
no flags Details
List of files which were modified when Eclipse ran as root (8.73 KB, text/plain)
2008-08-11 22:21 EDT, Sean Flanigan
no flags Details
List of files which were modified when Eclipse ran as root (8.95 KB, text/plain)
2008-08-11 22:29 EDT, Sean Flanigan
no flags Details
eclipse console log from comment 8 (83.47 KB, text/plain)
2008-08-13 23:48 EDT, Sean Flanigan
no flags Details
strace log from comment 8 (68.08 KB, text/plain)
2008-08-13 23:50 EDT, Sean Flanigan
no flags Details
~/.eclipse/ tarball from comment 8 (206.29 KB, application/octet-stream)
2008-08-13 23:51 EDT, Sean Flanigan
no flags Details

  None (edit)
Description Sean Flanigan 2008-08-11 03:18:12 EDT
Created attachment 313914 [details]
RPM containing French translations as plugin fragments

Description of problem:
Eclipse sometimes fails to pick up fragment plugins from /usr/share/dropins (or anywhere else I've tried).

Version-Release number of selected component (if applicable):
3.4.0-18

How reproducible:
Varies.  It has happened on three different virtual machine installations (two F9, plus one with all Rawhide updates).  It was happening on my desktop machine (F9) when I was running koji builds up to 3.4.0-18, but it somehow came good when I installed 3.4.0-18 from rawhide.(!)

Steps to Reproduce:
1. Install Fedora 9
2. yum --enablerepo=rawhide install eclipse-jdt
3. Download the attached eclipse-nls-fr-0.2.0-0.2.20080807snap.fc10.noarch.rpm and install through yum.  
4. Delete ~/.eclipse/
5. eclipse -nl fr
  
Actual results:
The dialog comes up in English.  [Upon choosing a workspace, the Babel plugins are not listed in Eclipse's About screens.]

Expected results:
A dialog allowing the user to choose a workspace directory should come up in French.  Upon choosing a workspace, the Babel plugins (org.eclipse.*.nl_fr) should be listed in Eclipse's About screens.

Additional info:
eclipse-nls-fr-0.2.0-0.2.20080807snap.fc10.noarch.rpm puts a number of plugin fragments under /usr/share/eclipse/dropins/babel-fr/eclipse/{plugins,features}.  Eclipse should be able to pick them up from there because of the line at the end of eclipse.ini:
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/usr/share/eclipse/dropins

NB: This works with upstream Ganymede 3.4.0, on the affected machines, including the case where eclipse dirs are read-only to the user running eclipse.
Comment 1 Andrew Overholt 2008-08-11 08:34:27 EDT
Since we patch nothing in the area of p2, this is in all probability an upstream bug.  I'm working on it upstream and will include a patch in our RPMs when I have something acceptable.
Comment 2 Andrew Overholt 2008-08-11 11:33:50 EDT
... and of course I can't duplicate :(
Comment 3 Sean Flanigan 2008-08-11 22:20:07 EDT
I have some more data, perhaps too much to be useful.  But see the log error message three paragraphs down - it might be significant.

On one of the affected virtual machines, I tried tarring up /usr/{lib,share}/eclipse.  I extracted this to a user directory on the same machine, edited eclipse.ini to suit, ran chown -R root.root, and found that the plugins weren't picked up.  The same tarball worked okay when extracted to my main desktop.  There must be some environmental factor which differs between the machines.  (OTOH my later results indicate that the problem is in the eclipse directories; see below.  Perhaps it is both.  Oh joy.)

I ran eclipse -nl fr -consolelog on the affected virtual machine and on my main desktop, and diffed the logs.  This was the only significant difference:

!ENTRY org.eclipse.equinox.p2.engine 4 4 2008-08-08 20:27:42.684
!MESSAGE An error occurred while collecting items to be installed
!SUBENTRY 1 org.eclipse.equinox.p2.engine 4 0 2008-08-08 20:27:42.685
!MESSAGE No artifact repository available.

On the same virtual machine, running /usr/lib/eclipse -clean as root picked up the translations, and after that the other users also got the translations.  Eclipse modified a number of files when run as root.  I will attach a list of the files which were modified, as touchedfiles.txt  One of these files must represent the difference between breaking and working.  Note that the error "No artifact repository available" still appeared in the console log.  

At this point, I tried running the previously untarred eclipse, and it is still broken, even though /usr/lib/eclipse is now working.  This tells me that the critical factor must be in the eclipse directories, presumably one of the files listed in touchedfiles.txt

However, on another F9 VM, running eclipse -clean as root achieved nothing.  Not even root got the translations.
Comment 4 Sean Flanigan 2008-08-11 22:21:23 EDT
Created attachment 314031 [details]
List of files which were modified when Eclipse ran as root
Comment 5 Sean Flanigan 2008-08-11 22:29:03 EDT
Created attachment 314033 [details]
List of files which were modified when Eclipse ran as root

Aligned filenames for readability.
Comment 6 Andrew Overholt 2008-08-12 10:23:29 EDT
Can you send me (here or via email or something) a tarball of ~/.eclipse when the issue is happening?

All those changed files is a good reason to not run Eclipse as root as it can mess things up for regular users :)

FWIW the "!MESSAGE No artifact repository available." message is what I was getting when this issue was happening for me with the CDT.  I'll see if I can reproduce and then debug and/or come up with a few instrumented JARs for you to plop into your installation so we can get some debug information.
Comment 7 Sean Flanigan 2008-08-13 23:34:19 EDT
(In reply to comment #3)
> However, on another F9 VM, running eclipse -clean as root achieved nothing. 
> Not even root got the translations.

Sorry, better disregard that bit.  All three virtual machines are now picking up the translations after running eclipse as root.  I can only assume that I previously ran it as user, but thinking I was root.
Comment 8 Sean Flanigan 2008-08-13 23:45:34 EDT
G'day Andrew,

(Sorry, yesterday was a public holiday here in Brisbane.)

(In reply to comment #6)
> Can you send me (here or via email or something) a tarball of ~/.eclipse when
> the issue is happening?

All three of my test VMs started working, which makes it a bit hard to provide the ~/.eclipse directory you asked for!  (And I should mention that I have generally been deleting ~/.eclipse before running Eclipse, so I'm not sure if it will help much.)

> All those changed files is a good reason to not run Eclipse as root as it can
> mess things up for regular users :)

Ha, yeah ;-)  But I find it a little surprising that Eclipse behaves that way.  It would be tidier if it used ~/.eclipse even when running as root, rather then quietly changing its behaviour depending on whether it has write access to ECLIPSE_HOME.  

I guess it's done that way because a lot of Eclipse users are used to running Eclipse from a writeable directory (on Windows, or under /home), and Eclipse historically kept its "mess" all in one place.

> FWIW the "!MESSAGE No artifact repository available." message is what I was
> getting when this issue was happening for me with the CDT.  I'll see if I can
> reproduce and then debug and/or come up with a few instrumented JARs for you to
> plop into your installation so we can get some debug information.

Since my test VMs stopped exhibiting the problem, I decided to use a fresh install of F9 and try again, documenting my steps:

-----------------------------------------
1. extract Fedora 9 VMware image from vmplanet.net (the smallest F9 image I could find, about 500MB): 
  http://vmplanet.net/node/49
2. change version numbers of VMware files (.vmx and .vmdk) to run under VMware Server 1.0x: 
  http://www.desktop-virtualization.com/2008/02/07/convert-vmware-server-20-vms-into-server-104/
3. reduce VM memory to 256MB (from 512)
4. log in as vmplanet, password is vmplanet.net
5. su - # root password is also vmplanet.net
6. #edited /etc/yum.repos.d/*.repo to point to local brisbane mirror
7. yum -y --enablerepo=rawhide install eclipse-platform openssl
8. yum install curl
9. curl -O http://seanf.fedorapeople.org/bugs/eclipse-nls-fr-0.2.0-0.2.20080807snap.fc10.noarch.rpm
10. rpm -i eclipse-nls-fr-0.2.0-0.2.20080807snap.fc10.noarch.rpm
11. yum install strace

12. [as vmplanet user] strace -etrace=open eclipse -nl fr -consolelog >eclipse.log 2>strace.log
13. #tarred up ~/.eclipse as user-eclipse-dir.tar.bz2
-----------------------------------------

Oh, and this *did* reproduce the problem - the workspace selection dialog came up in English, not French.  (In fact, I just did the whole thing again to make sure it was safe to remove some false steps from the list above, and it happened again.  That's all five of my virtual machines (plus my development machine) which have shown this problem when eclipse-3.4 was first installed.)

I will attach the log files and a copy of the ~/.eclipse directory which was created at step 12.  If they don't help, you could try installing the F9 VMware image to see if you can reproduce the problem.

In any case, I now have a system image I can use to run your instrumented jars under.

Sean.
Comment 9 Sean Flanigan 2008-08-13 23:48:27 EDT
Created attachment 314280 [details]
eclipse console log from comment 8
Comment 10 Sean Flanigan 2008-08-13 23:50:31 EDT
Created attachment 314281 [details]
strace log from comment 8
Comment 11 Sean Flanigan 2008-08-13 23:51:11 EDT
Created attachment 314282 [details]
~/.eclipse/ tarball from comment 8
Comment 12 Andrew Overholt 2008-08-14 09:10:51 EDT
Hi Sean,

(In reply to comment #8)
> (Sorry, yesterday was a public holiday here in Brisbane.)

Not a problem at all.

> (In reply to comment #6)
> > All those changed files is a good reason to not run Eclipse as root as it can
> > mess things up for regular users :)
> 
> Ha, yeah ;-)  But I find it a little surprising that Eclipse behaves that way.

Don't think I don't agree.

> I guess it's done that way because a lot of Eclipse users are used to running
> Eclipse from a writeable directory (on Windows, or under /home), and Eclipse
> historically kept its "mess" all in one place.

Yeah.

> 1. extract Fedora 9 VMware image from vmplanet.net (the smallest F9 image I

I can't say I've ever used VMware, but in theory my qemu virtual machine and/or my local F9-rawhide hybrid will be sufficient to reproduce.

> I will attach the log files and a copy of the ~/.eclipse directory which was
> created at step 12.

Cool, I'll take a look.

> In any case, I now have a system image I can use to run your instrumented jars
> under.

Great.  I'll try to get them to  you today or tomorrow.
Comment 13 Jens Petersen 2008-09-26 02:54:58 EDT
eclipse-nls langpacks are working for me now with current rawhide. :-)
Comment 14 Jens Petersen 2008-09-29 21:15:19 EDT
Hmm but not today... with another install.

(After running as root I see a localized eclipse.)
Comment 15 Andrew Overholt 2008-09-30 08:46:35 EDT
(In reply to comment #14)
> Hmm but not today... with another install.
> 
> (After running as root I see a localized eclipse.)

Don't run Eclipse as root :)
Comment 16 Sean Flanigan 2008-09-30 19:39:49 EDT
(In reply to comment #15)
> (In reply to comment #14)
> > Hmm but not today... with another install.
> > 
> > (After running as root I see a localized eclipse.)
> 
> Don't run Eclipse as root :)

True, but the Eclipse documentation <http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.user/tasks/running_eclipse.htm> does recommend running 
    eclipse -initialize
as a user with write permissions when using shared installs, apparently for performance reasons.  

Obviously, doing this as root is not advisable, but if the Eclipse files and directories were owned by the user "eclipse", we could have a post-install script to run
    eclipse -initialize -clean -nosplash
under the user "eclipse" whenever installing an Eclipse-related project.  If running as root does solve the problem, this approach should do it too, only more safely.

(What happens on a system where the user has already defined a user "eclipse"?  Is there a clean way to deal with this sort of thing?)
Comment 17 Jerry Amundson 2008-10-14 14:04:24 EDT
Me too. I see, for example, these rpm's freshly install from rawhide:
$ rpm -qa eclipse\*
eclipse-mylyn-webtasks-3.0.1-2.fc10.noarch
eclipse-changelog-2.6.2-2.fc10.x86_64
eclipse-cdt-5.0.0-6.fc10.x86_64
eclipse-cdt-mylyn-5.0.0-6.fc10.x86_64
eclipse-swt-3.4.0-24.fc10.x86_64
eclipse-subclipse-1.2.4-11.fc9.x86_64
eclipse-rcp-3.4.0-24.fc10.x86_64
eclipse-phpeclipse-1.2.0-0.4.svn1573.fc10.x86_64
eclipse-platform-3.4.0-24.fc10.x86_64
eclipse-rpm-editor-0.4.0-3.fc10.x86_64
eclipse-pydev-1.3.18-1.fc10.x86_64
eclipse-ecj-3.4.0-24.fc10.x86_64
eclipse-mylyn-3.0.1-2.fc10.noarch
eclipse-jdt-3.4.0-24.fc10.x86_64
... but eclipse only reports these features:
*** Features:
org.eclipse.cvs (1.1.0.v20080603-7C79E8M9EI99m9c9S) "Eclipse CVS Client"
org.eclipse.help (1.0.0.v20080603-7r7xEHJEJkZu5nE6Q4Qrtvu6JZ9L) "Help System Base"
org.eclipse.platform (3.4.0.v20080610-9I96EhtEm-T_5LxIsybz-3MdGZmOA3uwv7Ka_M) "Eclipse Platform"
org.eclipse.rcp (3.4.0.v20080324a-989JERhEk-jWnd5IY8K5tjxB) "Eclipse RCP"
org.fedoraproject.ide.feature (1.0.0) "Fedora Eclipse Product Plug-in"

Something is broken here.
Comment 18 shmuel siegel 2008-10-14 14:29:38 EDT
I installed f10 beta but kept my f9 home directory. I then yum installed eclipse-cdt which of course brought in other modules like eclipse-platform. But I found that eclipse-cdt was not one of my features. I then tried launching eclipse as root and that worked. So I went back to user and deleted ./eclipse. Now cdt is there. So it seems that eclipse doesn't know how to handle old config directories.
Comment 19 Andrew Overholt 2008-10-14 15:07:06 EDT
(In reply to comment #18)
> I installed f10 beta but kept my f9 home directory. I then yum installed
> eclipse-cdt which of course brought in other modules like eclipse-platform. But
> I found that eclipse-cdt was not one of my features. I then tried launching
> eclipse as root and that worked. So I went back to user and deleted ./eclipse.
> Now cdt is there. So it seems that eclipse doesn't know how to handle old
> config directories.

You shouldn't run eclipse as root as it will write things to /usr/lib{,64} that may cause issues in the future.  There is a separate issue here that running as root is not fixing :)

Also, you should probably get a new ~/.eclipse/org.eclipse.platform_3.4.0-<a hash of /usr/lib> alongside ~/.eclipse/org.eclipse.platform_3.3.0-<hash>.  Do you?
Comment 20 shmuel siegel 2008-10-14 19:01:37 EDT
I am not running it as root. Based on some comments in this bug I just wanted to see if root was properly configured. It was. So I tried the next step of deleting .eclipse. That made my cdt install work. It used to have both a patfor_3.4.0 and a platform_3.3.0. Now it only has patform_3.4.0 and it is working properly.
Comment 21 Jens Petersen 2008-10-20 02:01:35 EDT
I tested again today with current rawhide (with eclipse-3.4.1) and ja langpack worked okay for me again.


(In reply to comment #18)
Shmuel, your issue sounds different - I guess CDT is not using the dropins directory?
Could you you a separate bug report about your issue: I think incompatibility of 3.3 and 3.4
config may be a known issue though.
Comment 22 Jerry Amundson 2008-10-22 11:24:18 EDT
(In reply to comment #18)
and
(In reply to comment #21)
> I tested again today with current rawhide (with eclipse-3.4.1) and ja langpack
> worked okay for me again.

Right, "again", so it was working all along, or maybe at various times. For me at least, it never worked (add-on features).

> (In reply to comment #18)
> Shmuel, your issue sounds different - I guess CDT is not using the dropins
> directory?
> Could you you a separate bug report about your issue: I think incompatibility
> of 3.3 and 3.4
> config may be a known issue though.

Although 3.3->3.4 may come into play, I believe what's described here is all really just one bug, which, for me anyway, has just been fixed in rawhide. I now see features from CDT, PYdev, etc. that were not enabled before.
Comment 23 Mads Kiilerich 2008-10-27 16:21:52 EDT
*** Bug 468714 has been marked as a duplicate of this bug. ***
Comment 24 Jens Petersen 2008-10-28 07:13:22 EDT
Moving back to assigned based on bug 468714.
Comment 25 Bug Zapper 2008-11-25 21:44:07 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 26 Alexander Kurtakov 2009-01-19 05:52:02 EST
*** Bug 480557 has been marked as a duplicate of this bug. ***
Comment 27 Mads Kiilerich 2009-03-09 14:49:17 EDT
Uff. I just got this one on rawhide when installing eclipse-cdt-5.0.1-3.fc11.i586 :-(

It seems like "eclipse -clean" didn't help (IIRC it helped before...). But removing .eclipse "fixed" the problem ...
Comment 28 Andrew Overholt 2009-03-09 14:57:39 EDT
:(

I just verified that this appears to be fixed with 3.5 but there's little-to-no chance of it being fixed in 3.4.x.

We're going to try to do an update to 3.5.x in the F-11 cycle but it'll be risky.
Comment 29 Andrew Overholt 2009-03-10 16:03:28 EDT
Note that there's an upstream change in 3.4.2 that makes the -clean trick not work.  Crappy, I know :(
Comment 30 Alexander Kurtakov 2009-08-20 08:04:34 EDT
*** Bug 514077 has been marked as a duplicate of this bug. ***
Comment 31 Bug Zapper 2009-11-18 02:53:40 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 32 Bug Zapper 2009-12-18 01:17:38 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.