Community
Participate
Working Groups
I've just downloaded and installed Helios 3.6. When trying to install plugins (specifically Subclipse and FileSync, but I have a feeling it isn't specific to these two), the install process completes successfully and Eclipse restarts. When Eclipse opens back up, it is as if the plugins weren't installed. The UI is unaffected -- expected perspectives aren't available, Preferences dialog isn't updated, Project settings unaffected, etc. When checking the list of installed software, it claims the plugins are installed. Uninstalling and reinstalling plugins produce the same problems. This occurs with Eclipse for PHP Developers and Eclipse Classic (32 & 64 bit). -- Configuration Details -- Product: Eclipse 1.3.0.20100617-0520 (org.eclipse.epp.package.php.product) Installed Features: org.eclipse.platform 3.6.0.v20100602-9gF78GpqFt6trOGhL60z0oEx3fz-JKNwxPY
*** Bug 317897 has been marked as a duplicate of this bug. ***
Where did you unzip Eclipse? In "Program Files"?
In both Program Files and Program Files (x86). This is where I have always installed Eclipse. \Program Files\Eclipse\*
John, Simon, could you please try this on a Windows 7 box? Thx.
This might be a dup of bug 317757. We're not sure why yet however it appears Subvlipse is not working in an install when the base is read-only.
I noticed the same problem on my Win 7 machine. Also the list of available update sites is empty. So i imported the list of update sites from my OS X Helios installation. I also tried to extract Eclipse into a different location than "Program Files" which seems to work.
I have the same problem. In my case I installed the official eclipse tarball as root. And then started eclipse as a normal user. As a result the plugins where not downloaded and installed in the eclipse directory but in ~/.eclipse/org.eclipse.platform_3.5.0_1342668921/plugins After restarting the plugin was not available. The same for any other plugin. When I open "Manage configuration" (that is still lost in the menu at least since 3.5 and you have to define a key binding to reach it), I found errors like this: No plug-in: "net.sf.eclipsecs.branding" included at runtime. No plug-in: "net.sf.eclipsecs.core" included at runtime. No plug-in: "net.sf.eclipsecs.doc" included at runtime. No plug-in: "net.sf.eclipsecs.checkstyle" included at runtime. No plug-in: "net.sf.eclipsecs.ui" included at runtime.
Created attachment 172831 [details] Screenshot of Plugin-Problem
This is a show-stopper and the first thing that every advanced user rushes into. I can not believe that this was not tested.
(In reply to comment #7) > I have the same problem. In my case I installed the official eclipse tarball as > root. And then started eclipse as a normal user. I should have explicitly said that I am using linux (ubuntu) as this issue is filed for Windows 7.
(In reply to comment #7) > I have the same problem. In my case I installed the official eclipse tarball as > root. Did you run the multi-user initialization as root before you switched to your normal user? PW
(In reply to comment #4) > John, Simon, could you please try this on a Windows 7 box? Thx. I don't have windows 7, but I tried on Vista which I believe has similar behave with UAC. I wasn't able to reproduce this problem. I installed the Eclipse classic helios zip as Administrator in "c:\Program Files". I then started the application as a regular user, and I was able to install subclipse. After a reboot the SVN integration is working fine. As expected the subclipse plugins were installed under c:\users\<myuser>\.eclipse\org.eclipse.platform...\plugins.
(In reply to comment #7) > I have the same problem. In my case I installed the official eclipse tarball as > root. And then started eclipse as a normal user. > As a result the plugins where not downloaded and installed in the eclipse > directory but in ~/.eclipse/org.eclipse.platform_3.5.0_1342668921/plugins This is expected, since a regular user is not allowed to write under c:\Program Files. > > After restarting the plugin was not available. The same for any other plugin. > When I open "Manage configuration" (that is still lost in the menu at least > since 3.5 and you have to define a key binding to reach it), I found errors > like this: Although I don't see the same errors as you, note that this "configuration" dialog is part of the classic update mechanism and I wouldn't necessarily trust the information there. I.e., it could be just a bug in the compatibility mechanism that tricks classic update into believing it knows what is going on. To be sure of what is installed, look under Help > About > Installation Details.
(In reply to comment #13) > (In reply to comment #7) > > I have the same problem. In my case I installed the official eclipse tarball as > > root. And then started eclipse as a normal user. > > As a result the plugins where not downloaded and installed in the eclipse > > directory but in ~/.eclipse/org.eclipse.platform_3.5.0_1342668921/plugins > > This is expected, since a regular user is not allowed to write under > c:\Program Files. I guessed so and that is a great feature. > > > > > After restarting the plugin was not available. The same for any > > other plugin. > > When I open "Manage configuration" (that is still lost in the menu at least > > since 3.5 and you have to define a key binding to reach it), I found errors > > like this: > > Although I don't see the same errors as you, note that this "configuration" > dialog is part of the classic update mechanism and I wouldn't > necessarily trust the information there. I.e., it could be just a bug > in the compatibility mechanism that tricks classic update into believing > it knows what is going on. Thats interesting... You say that this is some sort of deprecated feature that has not been removed? What is then the way a regular user should figure out what went wrong if a plugin failes to start-up? > To be sure of what is installed, look under Help > About > Installation > Details. It shows up in "Installed Software" tab but not in "Plug-ins" or "Features". If found this one in the error log, that might be related: eclipse.buildId=I20100608-0911 java.version=1.6.0_18 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=de_DE Framework arguments: -product org.eclipse.epp.package.java.product Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.java.product -data /home/joerg/projects/mmm-workspace Error Sat Jun 26 10:37:26 CEST 2010 Error occurred while reading source bundle list. java.io.FileNotFoundException: /home/joerg/.eclipse/org.eclipse.platform_3.5.0_1342668921/configuration/org.eclipse.equinox.source/source.info (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:137) at java.io.FileReader.<init>(FileReader.java:72) at org.eclipse.update.internal.core.SiteStatusAnalyzer.loadSourceBundlesList(SiteStatusAnalyzer.java:332) at org.eclipse.update.internal.core.SiteStatusAnalyzer.status(SiteStatusAnalyzer.java:261) at org.eclipse.update.internal.core.SiteStatusAnalyzer.getStatus(SiteStatusAnalyzer.java:109) at org.eclipse.update.internal.core.SiteStatusAnalyzer.getFeatureStatus(SiteStatusAnalyzer.java:130) at org.eclipse.update.internal.core.LocalSite.getFeatureStatus(LocalSite.java:364) at org.eclipse.update.internal.ui.views.ConfigurationView$LocalSiteLabelProvider.getFeatureImage(ConfigurationView.java:295) at org.eclipse.update.internal.ui.views.ConfigurationView$LocalSiteLabelProvider.getImage(ConfigurationView.java:246) at org.eclipse.jface.viewers.WrappedViewerLabelProvider.getImage(WrappedViewerLabelProvider.java:117) at org.eclipse.jface.viewers.WrappedViewerLabelProvider.update(WrappedViewerLabelProvider.java:165) at org.eclipse.jface.viewers.ViewerColumn.refresh(ViewerColumn.java:152) at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:934) at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:102) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175) at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:1014) at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:481) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175) at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:2141) at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:829) at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:804) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:778) at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:644) at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:749) at org.eclipse.jface.viewers.AbstractTreeViewer.handleTreeExpand(AbstractTreeViewer.java:1444) at org.eclipse.jface.viewers.TreeViewer.handleTreeExpand(TreeViewer.java:952) at org.eclipse.jface.viewers.AbstractTreeViewer$4.treeExpanded(AbstractTreeViewer.java:1455) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:132) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1282) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1267) at org.eclipse.swt.widgets.Tree.gtk_test_expand_row(Tree.java:2105) at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:1775) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4378) at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method) at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:8163) at org.eclipse.swt.widgets.Display.eventProc(Display.java:1239) at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2224) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3169) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2629) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2593) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2427) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:670) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:663) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) 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)
Here is the problem as I see it. As of Windows Vista no program is allowed to write/modify anything under the "Program Files" or "Program Files (x86)" directories unless the program is running with Administrator privileges. Eclipse gets around this problem by creating a .eclipse directory in the user's home directory, and storing all the plugin configuration information there. However, as of Windows 7 this mechanism breaks in Eclipse. It still creates the .eclipse directory, but it does not manage it correctly. After you install the first plug-in, any additional plug-ins you install screws up the configuration information enough that all plug-ins are broken. You cannot solve the problem by removing plug-ins, you have to delete your .eclipse directory and start over. The work around to this problem is to run Eclipse with administrator privileges. A simple way to do this in Windows 7 is to edit the properties of the shortcut used to start Eclipse and go to the Compatibility tab, then select Run this program as and administrator. I suspect the problem with Eclipse in Windows 7 is that Windows 7 has changed/relaxed some of the security features and Eclipse is confused about what is going on.
By the way, the reason running Eclipse with Administrator privileges works is that if you have it installed in "Program Files" or "Program Files (x86)" then it is able to write directly into its installation directory, so it does not need to create a .eclipse directory in the user's home directory. Another workaround is to install Eclipse somewhere other than "Program Files" or "Program Files (x86)". In the long term the correct thing to do is simply fix Eclipse so that it works correctly when running under Windows 7 and it is installed under "Program Files" or "Program Files (x86)"
(In reply to comment #11) > (In reply to comment #7) > > I have the same problem. In my case I installed the official eclipse tarball as > > root. > > Did you run the multi-user initialization as root before you switched to your > normal user? Same problem for me. Extracted Helios with permissions root:root. I did not run any multiuser-initialization. I don't know what this should be, and even if I knew: Most users would not. Running such a thing should not be necessary.
An even simpler solution is to give your current (non-administrative) user full access rights to the Eclipse installation folder within Program Files. You can subsequently modify your "eclipse.ini" and add (I believe) a "-user" and "-data" switch pointing to the previous .eclipse folder (or any other location you'd like your user data stored). This way your user specific configuration data is still stored outside of the program files folder.
Rich, Are you sure the it happens with both Classic and the PHP package? I've been able to reproduce the problem with the EPP package, and I now know what's going on. However, I'm at a loss for why this would happen with Eclipse Classic.
*** This bug has been marked as a duplicate of bug 322929 ***
I have had the same problem with the Android ADT plugin. I am running 32 bit Eclipse Helios on Windows 7 with the JAVA EE Eclipse distribution. The ADT is the only plug in I have tried to install in this distribution.
(In reply to comment #12) > (In reply to comment #4) > > John, Simon, could you please try this on a Windows 7 box? Thx. > > I don't have windows 7, but I tried on Vista which I believe has similar behave > with UAC. I wasn't able to reproduce this problem. I installed the Eclipse > classic helios zip as Administrator in "c:\Program Files". I then started the > application as a regular user, and I was able to install subclipse. After a > reboot the SVN integration is working fine. As expected the subclipse plugins > were installed under > c:\users\<myuser>\.eclipse\org.eclipse.platform...\plugins. Wow - I can't believe this keeps coming back to bite me. I'm using Windows XP. I deleted my eclipse directory tree because I wanted to get rid of plugins I don't want anymore (whatever happened to the Uninstall option?) I unzipped the Helios archive into D:\eclipse, and I couldn't install anhy plugins either. Turns out extracting an archive in Windows leaves the entire directory tree with NO PERMISSIONS. Therefore eclipse went and installed everything in C:\ Documents and Settings\.... which is totally bogus. Eclipse doesn't even look in there when it starts up. I used a Cygwin bash shell, went into D:\eclipse, and added all permissions on everything in the directory tree. Suddenly Eclipse knows how to install plugins to that directory! Is there a way for Eclipse to warn that it cannot write to its own directory structure instead of defaulting to somewhere else? Thanks
(In reply to comment #22) > Wow - I can't believe this keeps coming back to bite me. > I'm using Windows XP. I deleted my eclipse directory tree because I wanted to > get rid of plugins I don't want anymore (whatever happened to the Uninstall > option?) Help -> About Eclipse Platform Click on Installation Details. From here you can select things that are installed, and uninstall them. > > Is there a way for Eclipse to warn that it cannot write to its own directory > structure instead of defaulting to somewhere else? Unfortunately no. This is called 'shared install' mode, and it's the default when Eclipse is placed in a read-only directory. The good news is that this is now fixed (or will be fixed when Helios SR1 (3.6.1) ships). Eclipse does look in the ~user_home/.eclipse directory for plug-ins, but a very strange glitch caused some problems. HTH, Ian
> > get rid of plugins I don't want anymore (whatever happened to the Uninstall > > option?) > > Help -> About Eclipse Platform > Click on Installation Details. > > From here you can select things that are installed, and uninstall them. > This is what I'm talking about. All the "Uninstall" buttons are greyed out. The only option is to "Disable" plugins.
