Community
Participate
Working Groups
At least since m6 (not sure whether this is PDE or Update) Update keeps sites in a dictionary keyed by URL.toExternalForm(). The site entry for the workspace as created by PDE is the path to the workspace parent dir in the form of a URL (having the drive letter as lowercase). If the workspace is immediately under the install (e.g. c:\eclipse\workspace), the site entry for the workspace will be file:/c:/eclipse/ while the site for the install will be file:/C:/eclipse/ (note the drive letter is capitalized). This causes a few problems: a) the workspace site ends up having the same features as in the install (didn't notice any bad effects) b) now that locations are stored as relative URLs, the difference between the URLs disappears, bringing confusion to Update (the second site to be processed is basically ignored, since Update believes it has already been installed) - see bug 97148.
However, I am surprised that this did not cause problems on other platforms. For instance, on Linux, if what I am saying above is true, it should be impossible to self host if the user has the workspace under the install. I guess I am missing some detail.
Dorian, is b. an issue? Having a workspace under the install has always been supported for self-hosting and never caused problems.
if I understand comment 2, having the workspace under the install has long been the standard and has not been problematic in any way.
More details on this: PDE won't add two sites for the same exact URL string (case sensitive), so this does not cause problems when creating the configuration. If the plug-in in the workspace and target have the same site URL string, PDE will create a single site. If they differ in case, because Platform.getInstallURL uses File.toURL() and PDE (LocalSite.getURL()) uses "new URL("file:" + path.addTrailingSeparator().toString())", they will end up being configured as different sites. b) since now we store paths as locations relative to the install, when we read them back, we use the same base URL to make them absolute, so the differences disappear. Wassim, I think Dorian won't be available today. But it is easy to verify that sites are supposed to use different URLs by looking at PlatformConfiguration#configureSite(ISiteEntry).
See also bug 97388.
Wassim, this has already been dealt with at Update level - see bug 97388. But the fix in Update requires PDE to take the same care when comparing paths, otherwise bad things will happen again. The affected code seems to be restricted to org.eclipse.pde.internal.core.TargetPlatform.addToSite() - the path comparison should ignore the case for the drive letter on Windows.
I wish this device issue would get resolved at the Core level once and for all (bug 49516) and not have us do all these checks.
DJ, before I add yet another workaround, is the filibuster still in effect for bug 49516?
+1 for this defect - it is a bit embarrasing that we treat d:\foo\bar and D:\foo\bar as two different paths - long overdue to fix it.
Bug 49516 won't be resolved for 3.1.
we now uppercase the device name if present, so that the IPath comparison doesn't fail.
