Community
Participate
Working Groups
Created attachment 147077 [details] Full .log of the problem. Build ID: Eclipse classic SDK M20090911-1628 (3.5.1 rc3) on WinXP SP3 I'm launching a shared Eclipse installation off an UNC path, but I would like to use my local -configuration such that I can enhance it with my own plugins. Here is the command line I am using, it is very easy to reproduce the issue with this: C:\Documents and Settings\mober>\\szg-rhfs\szg-rhfs03\t5-dev\uxTeam\eclipse\M20090911-1628\win32\eclipse\eclipse.exe -configuration "C:\Documents and Settings\mober\.eclipse-M20090911-1628\eclipse\configuration" This works fine when I map the UNC folder onto a drive letter and launch from that network drive. But when launching directly from a writable UNC location, the plugins in my -configuration are not picked up and I see this error in the error log: Could not load from shared install Unable to load parent configuration from: \\szg-rhfs\szg-rhfs03\t5-dev\uxTeam\eclipse\M20090911-1628\win32\eclipse\szg-rhfs03\t5-dev\uxTeam\eclipse\M20090911-1628\win32\eclipse\configuration\org.eclipse.update\platform.xml Apparently the UNC path is appended to the installation location again, resulting in an invalid path for platform.xml (full .log is attached). This is likely a duplicate of bug 235624, but I wanted to report it again here to be sure, and to indicate that this is a real-world problem. I'd like to roll out my shared installation with a team, but give each team member the chance to make local modifications to the config. Requiring each team member to map a drive letter onto the UNC path doesn't scale well. See also http://wiki.eclipse.org/Eclipse/UNC_Paths
Problem still exists with Eclipse 3.6m7 (I20100426-0852). This is a severe issue, because at first it looks like Eclipse can be started from the UNC path, but then there are subtle limitations after the fact (as per comment 0), making the user experience very problematic. Note that in a first step, I'm especially interested in the case of a Shared installation on an UNC drive that's read-only for clients, since I believe that's the most common scenario: roll-out of a shared installation to multiple network clients in a large organization which can't afford creating drive letters for everything - I have seen this at a large customer. To reproduce: 1.) Extract Eclipse onto UNC path 2.) Set everything read-only (to force shared install - typical end user scenario) 3.) Dbl click Eclipse .exe --> Eclipse comes up but there is an errorlog entry: Could not load from shared install java.lang.Exception at org.eclipse.update.internal.configurator.ConfigurationParser.processConfig(ConfigurationParser.java:314) at org.eclipse.update.internal.configurator.ConfigurationParser.startElement(ConfigurationParser.java:112) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) [...] at org.eclipse.update.internal.configurator.ConfigurationParser.parse(ConfigurationParser.java:76) at org.eclipse.update.internal.configurator.PlatformConfiguration.loadConfig(PlatformConfiguration.java:1089) at org.eclipse.update.internal.configurator.PlatformConfiguration.initializeCurrent(PlatformConfiguration.java:752) at org.eclipse.update.internal.configurator.PlatformConfiguration.<init>(PlatformConfiguration.java:104) at org.eclipse.update.internal.configurator.PlatformConfiguration.startup(PlatformConfiguration.java:707) at org.eclipse.update.internal.configurator.ConfigurationActivator.getPlatformConfiguration(ConfigurationActivator.java:398) at org.eclipse.update.internal.configurator.ConfigurationActivator.initialize(ConfigurationActivator.java:130) at org.eclipse.update.internal.configurator.ConfigurationActivator.start(ConfigurationActivator.java:68) [...] at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) [...] at org.eclipse.equinox.internal.ds.model.ServiceComponent.createInstance(ServiceComponent.java:457) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.createInstance(ServiceComponentProp.java:254) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:315) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:567) at org.eclipse.equinox.internal.ds.ServiceReg.getService(ServiceReg.java:53) at org.eclipse.osgi.internal.serviceregistry.ServiceUse$1.run(ServiceUse.java:120) [...] at org.eclipse.core.internal.runtime.InternalPlatform.getBundleGroupProviders(InternalPlatform.java:223) at org.eclipse.core.runtime.Platform.getBundleGroupProviders(Platform.java:1261) at org.eclipse.ui.internal.ide.IDEWorkbenchPlugin.getFeatureInfos(IDEWorkbenchPlugin.java:281) at org.eclipse.ui.internal.ide.WorkbenchActionBuilder.makeFeatureDependentActions(WorkbenchActionBuilder.java:1178) at org.eclipse.ui.internal.ide.WorkbenchActionBuilder.makeActions(WorkbenchActionBuilder.java:1001) at org.eclipse.ui.application.ActionBarAdvisor.fillActionBars(ActionBarAdvisor.java:147) at org.eclipse.ui.internal.ide.WorkbenchActionBuilder.fillActionBars(WorkbenchActionBuilder.java:335) at org.eclipse.ui.internal.WorkbenchWindow.fillActionBars(WorkbenchWindow.java:3527) at org.eclipse.ui.internal.WorkbenchWindow.<init>(WorkbenchWindow.java:414) at org.eclipse.ui.internal.tweaklets.Workbench3xImplementation.createWorkbenchWindow(Workbench3xImplementation.java:31) [...] at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
Actually, why is update.configurator even started with I20100426-0852 ? I had thought that all dependencies onto update.configurator had gone already.
Adding polish kwd as discussed on http://wiki.eclipse.org/Eclipse/PMC
Investigating.
Created attachment 167213 [details] Fix The problem was in ConfigurationParser where it converted from a URL to a file via "new File(url.getFile())". This is incorrect, since URL.getFile() discards the hostname, which is critical in a UNC path. The fix was to use URIUtil to convert to a file, which has special logic for "fixing" UNC paths when converting from a URL to a URI.
This patch also improves the exception message for this case, to make problems a bit easier to diagnose in the future.
Awesome! Though I'm still wondering why update.configurator is even involved when it is autostart=false and I'm just launching an SDK (Comment 2)?
(In reply to comment #7) > Awesome! Though I'm still wondering why update.configurator is even involved > when it is autostart=false and I'm just launching an SDK (Comment 2)? That happens because IDEWorkbenchPlugin.getFeatureInfos() obtains the IBundleGroupProvider service that is registered by org.eclipse.update.configurator. This fix for this is to have p2 provide that service instead (bug 236709).
Fix released. Note that with this fix the IDE starts with no errors, but if you attempt to install anything then bug 311789 occurs.
