Did you do the normal -clean and/or mv ~/.eclipse{,.bak20090909} dance?

Can you check the contents of the file .metadata/.log in your workspace looking for any exception related to subclipse?. I remember someone had problems with subclipse but it was a problem related with another plugin that was causing problems, but I do not find the details right now, after he removed the offending plugin subversion worked

I might observe the same thing:

$ rpm -qa | egrep "(eclipse|subclipse)"
eclipse-swt-3.5.0-0.10.fc12.i686
eclipse-pydev-1.4.7-3.fc12.i686
eclipse-findbugs-1.3.9-1.fc12.noarch
eclipse-gef-3.5.0-3.fc12.noarch
icu4j-eclipse-4.0.1-3.fc12.i686
eclipse-jdt-3.5.0-0.10.fc12.i686
eclipse-subclipse-graph-1.6.5-1.fc12.noarch
eclipse-emf-2.5.0-3.fc12.noarch
eclipse-mylyn-java-3.2.1-1.fc12.noarch
eclipse-platform-3.5.0-0.10.fc12.i686
eclipse-svnkit-1.3.0-1.fc12.noarch
eclipse-rpm-editor-0.4.3-1.fc12.i686
eclipse-changelog-2.6.7-3.fc12.i686
eclipse-rse-3.1-2.fc12.noarch
eclipse-mylyn-3.2.1-1.fc12.noarch
tomcat5-jasper-eclipse-5.5.27-7.4.fc12.noarch
eclipse-subclipse-1.6.5-1.fc12.noarch
eclipse-cdt-6.0.0-9.fc12.i686
eclipse-rcp-3.5.0-0.10.fc12.i686
eclipse-pde-3.5.0-0.10.fc12.i686

I've got some exception in my workspace/.metadata/.log like:
!ENTRY org.eclipse.team.core 4 0 2009-09-13 19:48:27.600
!MESSAGE Could not instantiate provider org.tigris.subversion.subclipse.core.svnnature for project java-wii-server-emulator.
!STACK 1
org.eclipse.team.core.TeamException: Could not instantiate provider org.tigris.subversion.subclipse.core.svnnature for project java-wii-server-emulator.
        at org.eclipse.team.core.RepositoryProvider.mapNewProvider(RepositoryProvider.java:165)
        at org.eclipse.team.core.RepositoryProvider.mapExistingProvider(RepositoryProvider.java:235)
        at org.eclipse.team.core.RepositoryProvider.getProvider(RepositoryProvider.java:507)
        at org.eclipse.team.internal.core.TeamHookDispatcher.getProvider(TeamHookDispatcher.java:97)
        at org.eclipse.team.internal.core.TeamHookDispatcher.getRuleFactory(TeamHookDispatcher.java:105)
        at org.eclipse.core.internal.resources.Rules.factoryFor(Rules.java:92)
        at org.eclipse.core.internal.resources.Rules.modifyRule(Rules.java:136)
        at org.eclipse.core.internal.resources.Project.touch(Project.java:1103)
        at org.eclipse.jdt.internal.core.SetContainerOperation.executeOperation(SetContainerOperation.java:115)
        at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800)
        at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:793)
        at org.eclipse.jdt.internal.core.JavaModelManager$11.run(JavaModelManager.java:2538)
        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800)
        at org.eclipse.jdt.internal.core.JavaModelManager.initializeAllContainers(JavaModelManager.java:2554)
        at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1773)
        at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:2652)
        at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2561)
        at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2662)
        at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1861)
        at org.eclipse.jdt.internal.core.JavaProject.isOnClasspath(JavaProject.java:2164)
        at org.eclipse.jdt.internal.ui.BuildpathIndicatorLabelDecorator.getOverlay(BuildpathIndicatorLabelDecorator.java:47)
        at org.eclipse.jdt.internal.ui.BuildpathIndicatorLabelDecorator.decorate(BuildpathIndicatorLabelDecorator.java:34)
        at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:269)
        at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:81)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:365)
        at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:347)
        at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:371)
        at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:331)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
!SUBENTRY 1 org.eclipse.team.core 4 0 2009-09-13 19:48:27.603
!MESSAGE Could not instantiate provider org.tigris.subversion.subclipse.core.svnnature for project java-wii-server-emulator.

I've already removed all ~/.eclipse*, had no effect.

Saw this bug and thought I'd update it with the information I posted to the mailing list:

I upgraded one of my boxes to Rawhide and see the same problem.

Eclipse is only loading the JDT and SDK features for me.

Funnily enough, these are the only plugins in
/usr/*lib*/eclipse/dropins whereas all the other plugins are
installing to /usr/*share*/eclipse/dropins. None of the plugins in
/usr/share/eclipse/dropins seem to be loaded at all.

If you symlink the plugins in /usr/share to /usr/lib like this:

 $ sudo ln -s /usr/share/eclipse/dropins/gef /usr/lib/eclipse/dropins

Then Eclipse does a cartoon double-take and realises that there are
plugins installed after all. So, it seems like Eclipse is not looking
in /usr/share/eclipse/dropins. Seems like an Eclipse bug, not a subclipse bug.

(In reply to comment #4)
> Saw this bug and thought I'd update it with the information I posted to the
> mailing list:
> 
> I upgraded one of my boxes to Rawhide and see the same problem.
> 
> Eclipse is only loading the JDT and SDK features for me.
> 
> Funnily enough, these are the only plugins in
> /usr/*lib*/eclipse/dropins whereas all the other plugins are
> installing to /usr/*share*/eclipse/dropins. None of the plugins in
> /usr/share/eclipse/dropins seem to be loaded at all.
> 
> If you symlink the plugins in /usr/share to /usr/lib like this:
> 
> $ sudo ln -s /usr/share/eclipse/dropins/gef /usr/lib/eclipse/dropins
> 
> Then Eclipse does a cartoon double-take and realises that there are
> plugins installed after all. So, it seems like Eclipse is not looking
> in /usr/share/eclipse/dropins. Seems like an Eclipse bug, not a subclipse bug.

This is clearly not the state for me.
Can you attach the output of eclipse -clean -debug -consolelog when /usr/share/eclipse/dropins is not symlinked?

Hmm, wierd. Before I made the symlinks, I was getting exceptions the same as Fabian posted above (one for each project under SVN source control).

It worked after I symlinked all the plugins to /usr/lib and continued to work even after removing the symlinks, so now I'm really confused. :-/

Ah ok, it came back after I deleted ~/.eclipse, let me attach the log.

Created attachment 360934 [details]
Eclipse Console Log

This is the log without symlinking the plugins.

Created attachment 360938 [details]
Eclipse Console Log

This is the log after symlinking the plugins with:

  $ cd /usr/lib/eclipse/dropins
  $ sudo ln -s /usr/share/eclipse/dropins/* .

Mat's last hint helped, after symlinking everything into /usr/lib/... eclipse recognizes all plugins.

So was the /usr/share-path removed from upstream?

Unfortunately Mat's log of the trouble case doesn't help at all.

There is no "/usr/share-path" upstream.  We just set a property in config.ini to make the dropins support also look there.  By default it looks in the "dropins" directory which is part of the Eclipse installation (/usr/lib/eclipse or /usr/lib64/eclipse in our case).

Can you try adding to your eclipse.ini the following  line and try again with a clean ~/.eclipse?
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/usr/share/eclipse/dropins

This seems to work.
I removed all symlinks added before, removed all ~/.eclipse* and added the line as noted by Alexander to /usr/lib/eclipse/eclipse.ini.

It appears we've lost the eclipse.ini modifications in rawhide.  I'm working on fixing it ASAP.

(In reply to comment #12)
> Can you try adding to your eclipse.ini the following  line and try again with a
> clean ~/.eclipse?
> -Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/usr/share/eclipse/dropins  

Yes, that seems to work. I removed all the symlinks and ~/.eclipse and the problem came back (just making sure) and then after adding this line, Eclipse can find its plugins once more.

I've fixed this in eclipse-build upstream (eclipse.org Linux Tools) and patched rawhide.  A build is going now:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1677557

This is fixed in Rawhide, thanks Andrew.

Thanks.