Community
Participate
Working Groups
WorkspaceResolver (which I see is part of debug.core...) returns null when 'path' doesn't exist in the workspace. This is annoying as it makes it impossible to use the ${workspace_loc:/proj/path} before the folder/file resource has been created on the filesystem. The WorkspaceResolver#resolveValue(...) returns a String that points at the absolute local fs location of the resource. Is there any good reason for the WorkspaceResolver not to return, what would be the location of the resource if it were to exist?
see also bug 244286#c1
I agree this is not an ideal behavior. I'm concerned though, that by changing it we would potentially be breaking compatibility with any plugin that use the workspace_loc dynamic variable.
(In reply to comment #2) > I agree this is not an ideal behavior. > > I'm concerned though, that by changing it we would potentially be breaking > compatibility with any plugin that use the workspace_loc dynamic variable. That is a worry. The issue is that null (or CoreException), isn't a very helpful answer. Effectively every caller, if they want to handle linked resources correctly, needs to do something like: try{ fStringValue = dynamicVar.getValue(fArgument); } catch(CoreException e) { fStringValue = null; // Bug 244286: Try a bit harder - hunt for substring from the path, and generate the location that would be created. if ("workspace_loc".equals(var.getName())) { //$NON-NLS-1$ IPath path = new Path(fArgument); IPath suffix = Path.EMPTY; while (path.segmentCount() > 0) { suffix = new Path(path.lastSegment()).append(suffix); path = path.removeLastSegments(1); try { fStringValue = dynamicVar.getValue(path.toString()); if (fStringValue != null) { fStringValue = new Path(fStringValue).append(suffix).toString(); break; } } catch (CoreException e2) { // Go around again } } } Which kinda defeats the point of using the variable resolver...
I agree that changing the existing behavior could have unintended consequences. Would be sufficient to add a new resolver method: IDynamicVariableResolver.resolveValueUnchecked()?
> Is there any good reason for the WorkspaceResolver not to return, what would be > the location of the resource if it were to exist? The workspace_loc variable has always been intended to point to a resource that currently exist - so to answer your question: no, there is no good reason other than "thats the way we designed it". > I agree that changing the existing behavior could have unintended consequences. > Would be sufficient to add a new resolver method: > IDynamicVariableResolver.resolveValueUnchecked()? I agree we should not change the current behavior, but that we should update the resolver to be able to properly handle linked content. I'm not sure how we would do this, we could add a new method to IDynamicVariableResolver2 (or similar) as Pawel suggested. Changing this to an enhancement request, because the workspace_loc variable has always been intended to point to a resource that already exists.
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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
