Bug 698415

Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

We are seeing a similar issue, however no matter how many times Eclipse is started the CDT plugin is not available to user.

Both Eclipse and CDT are installed from RPM

log in as (non-root)user and fire up eclipse doesn't give CDT

tried various combinations when running eclipse, including -initialize -clean 

If, however, I open a root session and launch eclipse once then it seems to initialize all the plugins for all (non-root) users.

This isn't really an option for us as our users don't have root privileges.

This is a known issue which results from the difference between how rpm installs plugins and how Eclipse does. We are working on a solution for this, but for the time being the best we can do is to try to avoid installation scenarios which aggravate this issue. In some situations asking the user to rm ~/.eclipse helps.

So I am curious how you ended up in this situation. Would you be able to post he output of this command:

diff `find /usr/lib64/eclipse -name bundles.info` `find ~/.eclipse -name bundles.info`

and tell me exactly how you installed Eclipse; was it a fresh install on a fresh system or an upgrade. Had you run eclipse as root previously etc.

Fixing needinfo email.

Hi,
the way we ended up in this situation is a fresh deployment, during the install
(via kickstart) we install eclipse and the relevant plugin packages (CDT being
one).

the machines were then given to our users, without root running eclipse.

We then recieved complaints that the CDT plugin wasn't installed, but to our
knowlege it was - thus my investigation.

I have found a workaround but this is less than ideal - to ssh to all
workstations as root and run /usr/bin/eclipse -initialize

Hi Jon,

Thanks for the additional info. I was able to reproduce this in RHEL 6.2 and I am working on it. It turns out that there are packages in the root bundles.info which are not installed in the system. They are provided by eclipse-pde. So the problem goes away if you install eclipse-pde. 

Because eclipse as regular user does not have the needed permissions to edit the installation it cant remove them from bundles.info. So it fails to load these missing packages and gives up on the rest of them (CDT). Long term we are working on a more robust solution.

*** Bug 713387 has been marked as a duplicate of this bug. ***

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Sami, where can we get your fix from ? I don't see such branch in git. Also can you provide a scratch build with your fix so it can be tested?

The branch with the fix is on eclipse not eclipse-cdt. I have started a scratch build.

Sami, 

I have not fixed that. It's Helios, isn't it?

The proper way of investigation would be:
1. Install everything
2. Launch once, backup bundles.info from the user dir
3. Repeat 2.

Once compared it should reveal what's the problem - besides Eclipse Helios lacks a number of patches that are in Juno, and which stabilize dropins a bit...

*** Bug 882287 has been marked as a duplicate of this bug. ***

Please ignore my previous comment - I have apparently ignored all the comments :-(.

Anyway, the diagnosis is correct. The fix too. I have reviewed changes in the code (OK) and checked that after installing eclipse-cdt and using a new build CDT is picked up on first launch.

FWIW, on a current production 6.2 system with the latest updates, this bug is still there.  That is, out of the box, installing all the proper rpms via yum, one cannot use eclipse with the cdt (or any other plugin of your choice installed via rpm).

It seems that the solution is as simple as asking eclipse to rebuild its config files using "/usr/bin/eclipse -initialize" (as root).

Very simplest solution: add a %post (and accompanying %postun) to each eclipse rpm's .specfile that executes "/usr/bin/eclipse -initialize".  That way, any change made to the system via the canonical RHEL yum/rpm system gets the config files rebuilt to reflect the current state of the eclipse plugins on that particular system.

(In reply to comment #25)
> FWIW, on a current production 6.2 system with the latest updates, this bug
> is still there.  That is, out of the box, installing all the proper rpms via
> yum, one cannot use eclipse with the cdt (or any other plugin of your choice
> installed via rpm).
> 
> It seems that the solution is as simple as asking eclipse to rebuild its
> config files using "/usr/bin/eclipse -initialize" (as root).
> 
> Very simplest solution: add a %post (and accompanying %postun) to each
> eclipse rpm's .specfile that executes "/usr/bin/eclipse -initialize".  That
> way, any change made to the system via the canonical RHEL yum/rpm system
> gets the config files rebuilt to reflect the current state of the eclipse
> plugins on that particular system.

Please, don't spread such suggestions as this would break stuff in a number of cases when some rpms are updated/removed/installed. The simplest workaround is to yum install eclipse-pde .

Installing eclipse-pde did not solve the problem.  It successfully added the plugin development project settings, but did not pick up any of the other plugins I'd installed via rpm previously.  So that suggestion just plain doesn't work (again, working out of the current production repositories).

On the other hand, "eclipse -initialize" did correct everything.

Also, I'm hardly "spreading suggestions" that could cause troubles to average users by suggesting changes to rpm spec files: RHEL itself controls those files for distribution.  Take it or leave it.  If someone's got the clue needed to roll their own rpm with tweaked .spec file, those guys aren't your problem anyway :)

If one have run eclipse as root once all the configs are modified in a way that only runnig eclipse again as root will fix. And one needs to do that on every plugin install.

The spreading suggestions was about ever running eclipse as root - for whatever reason one will do it, it will cause more harm than good. About the RPM part thanks for the suggestion.

I'd never run eclipse as root on the machines in question, although cannot verify that something in the install process hadn't done so at one point in time.  The initial install of these workstations (some time ago) included a partial set of eclipse rpms (including the cdt), but users hadn't ever tried to run them to uncover this bug till now: at which time a number of other eclipse rpms (including the pde) were installed via yum to see if that helped.  It's entirely possible that a completely fresh install behaves more sensibly, I haven't tested that.

*** Bug 886635 has been marked as a duplicate of this bug. ***

*** Bug 885129 has been marked as a duplicate of this bug. ***

What is the status of this bug? Is a fix in process? Thanks.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Requesting ack for RHEL 6.6

(In reply to Paul Carter from comment #33)
> What is the status of this bug? Is a fix in process? Thanks.

There exists a fix for this issue but unfortunately it did not make it into RHEL 6.5.

If possible, we recommend the use of Eclipse Kepler from DTS 2.0 where the issue does not happen.

Latest Eclipse offering for RHEL6 is now provided in Developer Toolset.