Community
Participate
Working Groups
Build ID: I20061214-1445 Steps To Reproduce: Using Eclipse 3.3M4 (also reproducible in 3.2) 1. Create a Java application that has an external dependency (i.e. code in another JAR file). 1. Create a Java Application launcher for this Java application 2. Specify an environment variable in the launch config (i.e. MY_DIRS=C:\somedir), where C:\somedir contains the external dependency 3. In the VM arguments of the launch config put -Djava.ext.dirs=${env_var:MY_DIRS} 4. Run the Java application (you should get NoClassDefFoundError for the missing class dependency) More information: According to bug 102419 this procedure works for Eclipse Application launch configurations, however the ${env_var:MY_DIRS} variables does not get resolved for Java Application launch configurations; For example, I get: "C:\Program Files\Java\jre1.5.0_10\bin\javaw.exe" -Djava.ext.dirs= -classpath "C:\Program Files\Eclipse\3.3M4\workspace\Test\bin" com.test.RunMe Notice that the value is missing for the java.ext.dirs system property. Other variables defined in the VM arguments do seem to work properly, it's just ${env_var} that does not. The same also applies if the ${env_var} is used in the Program Arguments.
Variable resolvers (in this case ${env_var}) work globally - they do not have a "context" (for example, a specific launch configuration). The string variables were not designed with this in mind, and an API for this does not exist. So, the env_var resolver works on the env_vars defined in the Eclipse process, not on new variables introduced into a specific configuration. The API for such string variables would be problematic, as different variable resolvers could support different contexts for resolution, and those using the API would not know what to pass into the resolution engine. marking as wontfix.
I also encountered this problem, but I couldn't understand Darin answer... If I have, in the arguments: ${env_var:TEMP} it is correctly expanded to my temp dir, but if I have: ${env_var:MYVAR} and MYVAR is defined in Environment tab, it is not expanded... The strange thing is that if I run an external batch program and I make a: echo %MYVAR% MYVAR is actually set in the environment variable. So, it seems that Arguments are resolved before variables in Environment tab is added to the actual environment. Why should custom environment variables be available for "Working Directoyy" but not for "Arguments"!? Mauro.
(In reply to comment #2) > So, it seems that Arguments are resolved before variables in Environment tab is > added to the actual environment. > Why should custom environment variables be available for "Working Directoyy" > but not for "Arguments"!? My testing shows that a "new/modified" variable does not work for either the Args or Working Dir. The problem is that the code/object that resolves the "env_var" variable does not know about the Environment tab - it only knows about the global state (i.e. existing environment variables).
Additional info... The variable resolution being used on the launch tabs is provided by the org.eclipse.core.variables plug-in that does not know about JDT or the debug platform. The API for variable resolution does not allow for extra state information to be passed into the resolution.
(In reply to comment #3) > My testing shows that a "new/modified" variable does not work for either the > Args or Working Dir. IMHO this is a problem: I saw some examples on the net where ${env_var} was used to set the working directory... so, as you say, they don't work if using newly defined variables... > The problem is that the code/object that resolves the "env_var" variable does > not know about the Environment tab - it only knows about the global state (i.e. > existing environment variables). But couldn't Eclipse set the new environment variables BEFORE that code is executed? Maybe this is about a more general architectural issue with the launch dialog... Anyway, IMHO this is a usability problem: Eclipse let you set new environment variables and also let you use a mechanism to access environment variables... BUT not the ones you have defined... At least, the documentation of env_var should say it. I fronted this problem when I had a case in which it would have been very useful if I could have defined my own variable and then use it to compose the Arguments... Apart from using the environment variables, I think you can't do in other ways... BUT the custom environment variables you define are not resolved, so it's a no way :-( Mauro.
(In reply to comment #5) > But couldn't Eclipse set the new environment variables BEFORE that code is > executed? Maybe this is about a more general architectural issue with the > launch dialog... The environment is set when executing a commnad line - but the command line has to be built before we can do the exec... I agree it is unfortunate that one cannot use "new" variables in this manner. The generic "String" variable substition feature does not support this sort of thing. Feel free to open a new feature request for such support - however, I don't expect that we will have resources to solve the problem in the near future.
I am sorry to wake up this dead ticket now, but I just bumped into the very same problem on Eclipse Kepler when trying to create an external tool configuration. It is absolutely counter-intuitive that this is not possible. Environment variables can be defined in a tool configuration, but then they cannot be used/resolved. Does that make any sense?
Well, here it is 4 years after the last registered comment and over a decade since this issue was first raised, and still it doesn't appear as if there is a (satisfactory) resolution. OK, so the official resolution is WONTFIX (which doesn't make any sense to me since this appears to be a rather desirable feature). So then, why does env_var show up when one presses on the Variables button when editing an Environment variable? From what people have been saying, env_var is effectively totally useless with respects to Environment variable creation. My grousing is born of the fact that I have spent some considerable amount of time trying to figure out why env_var wasn't working until I stumbled across this train of comments. Mario Molinari alluded to this (env-var appearing where it can't be used) 10 years ago but here it is, 2018, and it is still leading engineers astray down a dead end. Suggestion, would it not be possible for Eclipse to create a local copy of the environment in a buffer right at start up. This buffer could then be access by env_var at any time during execution of Eclipse? There ought to be something that could be done
