Community
Participate
Working Groups
in M2 it was possible to define the working directory of an external tool like that: ${project_loc}\classes Since I have lots of project, all with a \classes subdirectory, where all the compiled *.class files end up, I could reach them all using one external tool. The goal of the tool was to copy all the classes into an location external to Eclipse. Now Eclipse M3 doesn't like it, it also doesn't like ${project_loc} alone, regardless if I put it into external tool working directory or arguments. The same applies to ${workspace_loc}. So it looks like one cannot use several Eclipse variables to parametrize external tools. Note: the Help file still describes ${project_loc} in context of external tools as a valid variable.
I am able to specify ${workspace_loc} in the latest code, but not ${project_loc}.
Address for M5
The ${project_loc} variable works just fine if you have a resource selected. Without a selected resource, there's no context for determining which project to use.
Looks like the problem here is that the launch config is trying to expand the variable even while the dialog is up. If you don't have a resource selected, there's no context in which to expand the value of the project_loc variable.
Yes, that's what I also found out. instead of: ExpandVariableContext.EMPTY_CONTEXT (org.eclipse.ui.externaltools.launchConfigurations.ExternalToolsMainTab.java, method validateLocation, line 379 and method validateWorkDirectory line 411) I used VariableContextManager.getDefault().getVariableContext() and it has solved the problem. But it brings up a general question: this dialog is a general preference, something you should be able to edit no matter where you are in the workbench. Using the current context in such a place feels ugly IMO. Wouldn't it be better to refrain from validating the variables and just let it go whatever I place there? I mean even if the dialog proves that all the variables fit the current context I can run it from a diffent context (a wrong one) and make it crash. Another issue with variables is that it is disallowed to incorporate them within a string: see #29504. Question aside: in a case like this one, is it better to create a separate cases for the two of them (like I did), or put it together, since they are very close to each other (I mean source code changes would have effects in the same place: external tools dialog and execution).
The fix I'm working on to this problem is to change the validation to only check if the "tag" part of the variable (e.g. "project_loc") is valid. We won't actually expand the value of the variable until the config is launched.
It would be extremely useful to be able to use Workbench|Path Variables as well.
Fixed. Please verify.
Verified.
