Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Added check for not intended default workspace location use (eclipse-…
…platform#35) See original bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=514333 that was only partly fixed. The original fix added -Dosgi.dataAreaRequiresExplicitInit=true system property and changed org.eclipse.core.internal.runtime.DataArea in the way that it doesn't allow to initialize itself if the workspace location was not explicitly specified yet - either via -data or via workspace selection prompt. But the fix in DataArea does not work if bad client code calls Platform.getLocation() *before* calling Plugin.getStateLocation(), because Platform.getLocation() doesn't run into changed DataArea code at all. Exact this happened in commit eclipse-platform/eclipse.platform.resources@a8a8d82 where workspace init order was slightly changed: original code initialized LocalMetaArea first (which then failed as supposed in assertLocationInitialized() if workspace was not set yet), and after that initialized WorkspaceRoot (which uses Platform.getLocation() after the check). Changed code initialized WorkspaceRoot first, and because this uses Platform.getLocation(), the code silently initializes default workspace location even if -Dosgi.dataAreaRequiresExplicitInit=true is set. The current fix makes sure that if the system flag is given, we disallow silent workspace location initialization by adding similar check in Platform.getLocation(). Fixes issue eclipse-platform#35
- Loading branch information