Community
Participate
Working Groups
This may be a duplicate, but I couldn't find it... It should be possible to create a linked resource relative to the 'dynamic' variable ${workspace_loc:}. Using paths relative to WORKSPACE_LOC results in simple string concatenation. This makes it impossible to place projects anywhere on disk, import them, and have links pointing into them work.
Oh, I see the problem. Instead of having a path relative to the file system location of the workspace, you would like to have a linked resource that resolves the workspace path "/project/dir/", and have the path be based off this? Right now, there's no such variable provided by default. But you can create one yourself, using the core resource variable resolver extension point. Note that there are some limitations right now, including: 1) it can't use the same syntax as core.variables, since ":" is a path delimiter on some OS, as well as '/'. So setting the value "${workspace_loc:/foo/bar}" would need to be recorded internally as something like "WORKSPACE_PATH-foo-bar" 2) There's no user-friendly editor to let the user easily build the link resource value, so the user has to enter that clunky format himself at the moment. Here's what the extension point would should be: <extension point="org.eclipse.core.resources.variableResolvers"> <variableResolver class="sample.workspace_relative_path.WorkspaceRelativePath" variable="WORKSPACE_PATH"> </variableResolver> </extension> And the implementation: package sample.workspace_relative_path; import java.net.URI; import org.eclipse.core.resources.IResource; import org.eclipse.core.resources.variableresolvers.PathVariableResolver; import org.eclipse.core.runtime.Path; public class WorkspaceRelativePath extends PathVariableResolver { public String[] getVariableNames(String variable, IResource resource) { return new String[] {"WORKSPACE_PATH"}; } @Override public String getValue(String variable, IResource resource) { int index = variable.indexOf('-'); if (index == -1 || index == (variable.length() -1)) return ""; String argument = variable.substring(index + 1); argument = "/" + argument.replace('-', '/'); IResource target = resource.getWorkspace().getRoot().findMember(Path.fromOSString(argument)); if (target == null) return ""; URI value = target.getLocationURI(); if (value == null) return null; return value.toASCIIString(); }
bug 312760 is a dependent in order to be able to conveniently edit macros without having to encode values by hand.
Wow, that was fast - thanks Serge! That's exactly right. We've extended CDT a fair bit to allow headless project import trees of projects, building them, dumping markers, etc. See the org.eclipse.cdt.managedbuilder.core.headlessbuild IApplication for it's full functionality. Currently the CDT MBS can handle arbitrary project location URIs. So having linked resources which use workspace paths would be really useful where projects aren't directly checked out under the workspace.
Thanks for the example! It would probably be worth falling back to getFile / getFolder if the path segment lenght > 1 && findMember returns null. This would allow handling resources which may not yet exist or go in and out of existence. I agree this is a special case of handling arbitrary variables. But it would no doubt be harder / impossible to reference UI dependent variables without stashing the most recent selection.
*** Bug 336265 has been marked as a duplicate of this bug. ***
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
