Bug 731416 - Installing eclipse-jdt after eclipse-cdt makes jdt not usable
Installing eclipse-jdt after eclipse-cdt makes jdt not usable
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
14
Unspecified Linux
unspecified Severity high
: ---
: ---
Assigned To: Jeff Johnston
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-17 11:10 EDT by Marcin Rzeźnicki
Modified: 2011-08-30 14:22 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-30 14:22:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marcin Rzeźnicki 2011-08-17 11:10:05 EDT
After installing eclipse-jdt on top of existing cdt installation there is no way to create java project etc. Running /usr/bin/efj (whatever that is - I assumed it was EclipseForJava) results in error:
!ENTRY org.eclipse.osgi 4 0 2011-08-17 17:08:57.923
!MESSAGE Application error
!STACK 1
java.lang.RuntimeException: Application "org.eclipse.jdt.core.JavaCodeFormatter" could not be found in the registry. The applications available are: org.ecli
pse.ant.core.antRunner, org.eclipse.equinox.app.error, org.eclipse.equinox.initializer.configInitializer, org.eclipse.equinox.p2.director.app.application, or
g.eclipse.equinox.p2.director, org.eclipse.equinox.p2.garbagecollector.application, org.eclipse.equinox.p2.metadata.generator.EclipseGenerator, org.eclipse.e
quinox.p2.publisher.InstallPublisher, org.eclipse.equinox.p2.publisher.EclipseGenerator, org.eclipse.equinox.p2.publisher.ProductPublisher, org.eclipse.equin
ox.p2.publisher.FeaturesAndBundlesPublisher, org.eclipse.equinox.p2.reconciler.application, org.eclipse.equinox.p2.repository.repo2runnable, org.eclipse.equi
nox.p2.repository.metadataverifier, org.eclipse.equinox.p2.artifact.repository.mirrorApplication, org.eclipse.equinox.p2.metadata.repository.mirrorApplicatio
n, org.eclipse.equinox.p2.updatesite.UpdateSitePublisher, org.eclipse.equinox.p2.publisher.UpdateSitePublisher, org.eclipse.equinox.p2.publisher.CategoryPubl
isher, org.eclipse.ui.ide.workbench, org.eclipse.update.core.standaloneUpdate, org.eclipse.update.core.siteOptimizer, org.eclipse.cdt.codan.core.application,
 org.eclipse.cdt.core.GeneratePDOM, org.eclipse.cdt.managedbuilder.core.headlessbuild, org.eclipse.datatools.connectivity.console.profile.StorageFileEditor.
        at org.eclipse.equinox.internal.app.EclipseAppContainer.startDefaultApp(EclipseAppContainer.java:248)
        at org.eclipse.equinox.internal.app.MainApplicationLauncher.run(MainApplicationLauncher.java:29)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
        at org.eclipse.equinox.launcher.Main.main(Main.java:1383)
        at org.eclipse.core.launcher.Main.main(Main.java:34)
Comment 1 Andrew Overholt 2011-08-17 11:27:37 EDT
This is almost 100% caused by some dropins issue.  Please paste here the output of:

rpm -qa | grep eclipse
rpm -qV eclipse-*

Have you tried with a clean ~/.eclipse?
Comment 2 Marcin Rzeźnicki 2011-08-17 11:50:03 EDT
Sure:


rpm -qa | grep eclipse
tomcat5-jasper-eclipse-5.5.29-3.jpp6.noarch
eclipse-swt-3.6.1-6.2.fc14.i686
eclipse-callgraph-0.6.1-1.fc14.i686
eclipse-gef-3.6.1-1.fc14.noarch
eclipse-subclipse-1.6.16-1.fc14.noarch
eclipse-valgrind-0.6.1-1.fc14.i686
eclipse-pde-3.6.1-6.2.fc14.i686
eclipse-rcp-3.6.1-6.2.fc14.i686
eclipse-svnkit-1.3.3-5.fc14.noarch
eclipse-emf-2.6.0-2.fc14.noarch
eclipse-oprofile-0.6.1-1.fc14.i686
eclipse-linuxprofilingframework-0.6.1-1.fc14.i686
eclipse-jdt-3.6.1-6.2.fc14.i686
eclipse-cdt-7.0.1-7.fc14.i686
eclipse-birt-2.5.2-1.fc14.noarch
eclipse-systemtapgui-1.1-1.fc14.noarch
eclipse-platform-3.6.1-6.2.fc14.i686
eclipse-subclipse-graph-1.6.16-1.fc14.noarch
eclipse-dtp-1.8.1-1.fc14.noarch
eclipse-rse-3.2-1.fc14.noarch
icu4j-eclipse-4.2.1-1.fc14.i686


rpm -qV eclipse-jdt
rpm -qV eclipse-cdt

(no output - that is)

rpm -qV eclipse-platform
S.5....T.  c /etc/eclipse.ini
....L....    /usr/lib/eclipse/plugins/org.apache.lucene.analysis_1.9.1.v20080530-1600.jar

And no - cleaning ~/.eclipse did not help
Comment 3 Andrew Overholt 2011-08-17 12:32:27 EDT
Jeff, please take a look since you have an F14 box to try.
Comment 4 Jeff Johnston 2011-08-17 16:40:13 EDT
(In reply to comment #3)
> Jeff, please take a look since you have an F14 box to try.

I wasn't able to reproduce.  The tomcat5-jasper-eclipse package is a JPP package and I upgraded to it since it is beyond the one for F14.  I then upgraded my eclipse-platform, eclipse-pde, eclipse-jdt, eclipse-swt, and eclipse-rcp to 3.6.1-6.2.  I already had the same level of CDT as mentioned above so it should have been similar to the scenario quoted.

Using efj after that:

bash $ /usr/bin/efj -config /notnfs/jjohnstn/workspace-cdt-8.0/org.eclipse.cdt.core/.settings/org.eclipse.jdt.core.prefs  my/some.java
Configuration Name: /notnfs/jjohnstn/workspace-cdt-8.0/org.eclipse.cdt.core/.settings/org.eclipse.jdt.core.prefs
Starting format job ...
The Eclipse formatter failed to format /home/jjohnstn/my/some.java. Skip the file.
Done.

The efj binary is not the way to start Eclipse for Java.  It is for using the Java code formatter without having to start up the Eclipse IDE.
Comment 5 Jeff Johnston 2011-08-17 17:17:57 EDT
(In reply to comment #2)
> Sure:
> 
> 
> rpm -qa | grep eclipse
> tomcat5-jasper-eclipse-5.5.29-3.jpp6.noarch
> eclipse-swt-3.6.1-6.2.fc14.i686
> eclipse-callgraph-0.6.1-1.fc14.i686
> eclipse-gef-3.6.1-1.fc14.noarch
> eclipse-subclipse-1.6.16-1.fc14.noarch
> eclipse-valgrind-0.6.1-1.fc14.i686
> eclipse-pde-3.6.1-6.2.fc14.i686
> eclipse-rcp-3.6.1-6.2.fc14.i686
> eclipse-svnkit-1.3.3-5.fc14.noarch
> eclipse-emf-2.6.0-2.fc14.noarch
> eclipse-oprofile-0.6.1-1.fc14.i686
> eclipse-linuxprofilingframework-0.6.1-1.fc14.i686
> eclipse-jdt-3.6.1-6.2.fc14.i686
> eclipse-cdt-7.0.1-7.fc14.i686
> eclipse-birt-2.5.2-1.fc14.noarch
> eclipse-systemtapgui-1.1-1.fc14.noarch
> eclipse-platform-3.6.1-6.2.fc14.i686
> eclipse-subclipse-graph-1.6.16-1.fc14.noarch
> eclipse-dtp-1.8.1-1.fc14.noarch
> eclipse-rse-3.2-1.fc14.noarch
> icu4j-eclipse-4.2.1-1.fc14.i686
> 
> 
> rpm -qV eclipse-jdt
> rpm -qV eclipse-cdt
> 
> (no output - that is)
> 
> rpm -qV eclipse-platform
> S.5....T.  c /etc/eclipse.ini
> ....L....   
> /usr/lib/eclipse/plugins/org.apache.lucene.analysis_1.9.1.v20080530-1600.jar
> 
> And no - cleaning ~/.eclipse did not help

Noticing that you have JPP packages installed, this may very well be the root of all your problems.  It isn't clear whether JPP packages have proper OSGI metadata in them (i.e. we don't know).  When Eclipse is trying to resolve the JDT and in your case the JavaCodeFormatter application, if the OSGI meta-data of the dependencies of the JDT are missing or are incorrect, it will not load.

I would suggest you do an rpm -qa and see what packages you have that are JPP packages and try replacing these with Fedora packages (which will have the correct OSGI meta-data).

You can figure out what yum sees as the recursive list of dependencies of eclipse-jdt using the repoquery command.  You can then start replacing the packages and seeing if /usr/bin/efj at least gives you the help contents.
Comment 6 Alexander Kurtakov 2011-08-18 01:43:40 EDT
JPP doesn't ship OSGi metadata in most of its packages and if it happens to be Eclipse or some of the Eclipse plugins you have installed dependency this will break you installation.
Eclipse from Fedora has never been tested to work with any 3rd party repository and there is nothing we can do helping people but tell them use only Fedora packages or debug the issue yourself.
Comment 7 Marcin Rzeźnicki 2011-08-27 14:29:08 EDT
Hi,
Ok then - I've gone through chores of replacing jpp6 packages. I've set jpp6 repo priority to something very high, like 99, run yum distro-sync, watched it fail :-) , removed some stuff manually, run it again and so on. At last jpp6 eclipse dependencies have been removed. yum check all does not report any broken dependencies. All seems to be clean, but still I cannot use jdt. I noticed something weird in an error log:
!ENTRY org.eclipse.equinox.p2.engine 4 4 2011-08-27 20:22:08.075
!MESSAGE An error occurred while installing the items
!SUBENTRY 1 org.eclipse.equinox.p2.engine 4 0 2011-08-27 20:22:08.075
!MESSAGE session context was:(profile=PlatformProfile, phase=org.eclipse.equinox.internal.p2.engine.phases.Install, operand=null --> [R]org.apache.xml.resolver 1.2.0.v200806030312, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction).
!SUBENTRY 1 org.eclipse.equinox.p2.touchpoint.eclipse 4 0 2011-08-27 20:22:08.075
!MESSAGE The artifact file for osgi.bundle,org.apache.xml.resolver,1.2.0.v200806030312 was not found.

Needless to say, xml resolver is installed (from Fedora's repos).
Comment 8 Marcin Rzeźnicki 2011-08-27 14:37:42 EDT
Ok, I managed to get rid of this error by running eclipse --clean , still no "sign" of jdt. Any recommendations?
Comment 9 Andrew Overholt 2011-08-29 09:31:37 EDT
Thanks for doing all this!  If you're 100% positive you have no JPackage packages on your system, please again run rpm -qVa eclipse-*.  If that shows no problems, I recommend:

yum remove icu4j-eclipse sat4j tomcat5-jasper-eclipse lucene jsch jetty tomcat*-jsp* tomcat*-servlet-*

Then, verify /usr/lib{,64}/eclipse and /usr/share/eclipse do not exist.  If they exist, remove any RPMs that own them (rpm -qf <file> will tell you what package owns <file>).  Finally, `yum install eclipse-{cdt,jdt}` and mv ~/.eclipse{,.bak20110829} before starting Eclipse for the first time.  I hope this works.

If it doesn't work, is there any chance I could ssh to your machine to see what's up?
Comment 10 Andrew Overholt 2011-08-29 09:32:36 EDT
Oh, I forgot, please also try removing these (in the yum remove line above):  hamcrest, objectweb-asm
Comment 11 Marcin Rzeźnicki 2011-08-30 11:46:08 EDT
Hi,
Thanks a lot for your feedback, it really helped me to get rid of these annoying issues. After removing all eclipse packages, icu4j-eclipse, tomcat5-jasper-eclipse and, manually, /home/.eclipse and installing them again (simple yum reinstall didn't work for me) jdt is usable. I assume then that jpp packages were the root of all problems. I am still not sure why simply removing jpp did not work in the first place, or why eclipse-cdt updates were causing issues with autotools plugins but for now I am more happy with my eclipse installation then ever. Thanks a lot for your the most valuable input. I am guessing that this bug can be closed (should I?).
Comment 12 Andrew Overholt 2011-08-30 14:22:26 EDT
Thank *you* for your incredible patience and excellent follow-through on this bug, Marcin!  We really appreciate you reporting issues so that we can find and fix problems.  I'm glad your system is back to normal.  You could have closed this bug but I'll do it since I'm here now.

Take care,

Andrew

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