I have Eclipse Helios with a java program set up. I'm attempting to create two environment variables
ReportingManagerHome=C:\rp
ReportingManagerConfig=${ReportingManagerHome}\config
I then run my program with
System.out.println(System.getenv("ReportingManagerConfig"));
Eclipse doesn't even call the java compiler. It throws up a pop up window with the error that environment variable ReportingManagerHome is not defined. I understand that since the java compiler has yet to be called, technically Eclipse is correct.
Now how do I work around this so that I can define cascading environment variables in Eclipse?
It won't recursively expand environment variables from the launch config.
Even using ${env:VAR} takes it from the environment variables from your eclipse process, not from your current launch config.
The most reliable way to do it is to go to Preferences>Run/Debug>String Substitution and define an eclipse variable there.
Then define the environment variables in your launch config:
ReportingManagerHome=${RMH}
ReportingManagerConfig=${RMH}\config
In Eclipse Mars and later you can use
${env_var:VAR_NAME}
Related
Does Pydev provide dynamic substitution variables, specifically one that could be used to identify the Python interpreter used in a Pydev project?
I would like to use the Eclipse plugin EasyShell to define a command that has to know whether it is executed in the context of a Python 2 or Python 3 project. EasyShell commands can parameterized with Eclipse substitutition variables. Of course, other suggestions how to achieve my goal are welcome.
Edit: To be a little more specific, in Eclipse I have defined an EasyShell command with the substitution variables ${easyshell:container_loc} and ${easyshell:project_name} as parameters. The command executes a bash script that uses the variable values to locate the source folder of the Python project and eventually calls pylint. I would like to add a parameter to the command that hints at the Python interpreter specified in Pydev for the project. Hopefully, I could then find out whether its a Python 2 or Python 3 project and call the version of pylint.
I don't think there's such a variable from PyDev to be used.
To give more suggestions I'd need more info on what exactly are you trying to achieve...
I'm working on a project developing an Eclipse-based application. Running a JUnit plug-in test requires the run configuration for it to have a bunch of parameters set. This means that if I want to run a single test class or method, as far as I can tell I have to create a new configuration or edit one that I reuse. More annoyingly I can't use the convenience of Alt+Shift+X, P.
Is there a way to tell Eclipse that a bunch of parameters are the defaults for an implicitly created run configuration of a given type to use it when it's automagically creating one?
If you are using a custom target platform (which you should use anyway), you can specify Program arguments and VM arguments on the Environment tab of the target platform editor.
They will be used as default values for PDE launch configurations.
I have been searching for a good way to use python virtual environments from within eclipse.
The only suggestion I have found is to create a new eclipse-wide "interpreter" for each virtual environment. That is cumbersome for many project, but it works.
I want to have a virtual environment per project, so the path to the interpreter will have to change for each project.
1) can you define an interpreter specific for a project?
2) alternatively, how do you define an interpreter that use e.g. PROJECT_LOC variable?
any suggestions are welcome
Unfortunately, the way that PyDev works, it expects all interpreters to be configured "eclipse-wide" (and then in a given project you can say which one should be used for that particular project if it shouldn't be the default one).
The other option is actually having one Eclipse workspace per project (then you'd configure a single "eclipse-wide" interpreter for it).
Another option, if the interpreters are from the same Python version and you're only changing the installed libraries would be creating a single "eclipse-wide" interpreter as the default one for all projects and then configuring the additional paths to be included in the PYTHONPATH per project.
Personally what I usually do is having one Eclipse workspace per project and having everything independent as I'm usually working on a single project at a time (so, I can focus only on what it's important for it), so, switching projects would be opening a new Eclipse instance pointing to the proper place, although it depends quite a lot on your use case (which you haven't actually made explicit) -- each project would have its own virtual env configured "eclipse-wide" (although in my case it's actually conda virtual envs).
Using ARM DS-5 environment, based on Eclipse 4.3.2, I defined a C project and using a Makefile to build it. The Makefile contains a few module selection variables, which are set to Y or N depending on whether we want to include the module or not.
I am trying to set these variables from the project settings. Thus, I use the following construct to have a default setting in the Makefile:
Module_1 ?= Y
Module_2 ?= Y
Now, I want to add a project variable Module_1 set to Y or N. It happens that there are Build Variables and Environment Variables under C/C++ Build. When I add Module_1 N to the Environment Variables, it overrides the default setting. However, When I do the same in the Build Variables it has no effect.
What is the difference between the two types of variables?
As far as I understand:
Build variables can be accessed within Eclipse only. They may influence other Eclipse components. You can also reference those variables in Eclipse make targets e.g.:
make ${name_of_variable} (note the braces)
where "name_of_variable" would be declared in the "Build Variables" menu of Eclipse. Those variables can be passed as arguments to external tools, but they are not part of the shell environment of those tools.
Environment variables can be accessed from external tools launched during the build process (e.g. GNU make: if you declare "env_variable" in the "Environment Variables" of Eclipse, you can use it in a makefile using the syntax $(env_variable) (note the parenthesis)). They become part of the shell environment of the external tool. Note that they can also be used as build variables within Eclipse. In addition you can invoke build variables in the declaration of environment variables, e.g. my_env_var = ${my_build_var} and vice-versa.
The misleading point is that when you tick "Show system variables" in the "Build variables" configuration page of Eclipse, you see the environment variables of the Eclipse IDE itself, plus the environment variables that you defined within Eclipse.
I'm not a developer of Eclipse so I cannot justify the rationale for the above behavior. I suspect that the intent is to avoid collisions between variables that are useful internally to the IDE only, and variables that should propagate to the environment of the external tools. I would have preferred to have a single variable type in Eclipse, and a choice to export them or not (by ticking a checkbox "export" for example). It would have made more sense.
In the run configuration of eclipse, you are provided with a set of default variables that you can use in the VM arguments, like container_path and env_var.
What I want to access is a classpath variable, M2_REPO, but can't see a way of doing this. I need to specify a javaagent in the VM arguments, which requires a path to a jar file. This jar file lives in the maven repository, but I can't find a way of specifying the path to the maven repository using the already configured M2_REPO Classpath variable (configured in windows->preferences->java->Build Path->Classpath variable). What I would like to do is use this as my VM arguments but can't because classpath_var isn't a real variable.
-javaagent:${classpath_var:M2_REPO}/org/apache/openjpa/openjpa/2.1.0/openjpa-2.1.0.jar
Is there any other way of accessing the value of M2_REPO in VM arguments?
This isn't exactly what you asked for, but it worked for us as a way of sharing a codebase and not having hard coded paths in our run configurations. Rather than using a classpath variable, use a string substitution variable (configured in windows -> preferences -> run/debug -> String Substitution). Set it to the same path as the value of M2_REPO and save. Using the above example if your string substitution variable name was also M2_REPO, the VM Argument would be
-javaagent:${M2_REPO}/org/apache/openjpa/openjpa/2.1.0/openjpa-2.1.0.jar
To be even more clear, I would personally just create an openjpa_2_1_0_agent string substitution variable that went directly to your open jpa jar.