Summary: | workspace site ends up having same URL as install site | ||
---|---|---|---|
Product: | [Eclipse Project] PDE | Reporter: | Rafael Chaves <eclipse> |
Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | dj.houghton, jeffmcaffer, pombredanne, wassim.melhem |
Version: | 3.1 | ||
Target Milestone: | 3.1 RC2 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Rafael Chaves
2005-05-30 03:09:37 EDT
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). 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. |