Community
Participate
Working Groups
Hi, I have an environment variable, FIT_HOME, and I need to add an eclipse variable (Window->Preferences, Java, Build Path, Classpath Variables) that maps to this environment variable. Is there a way to do this? I have tried but Eclipse 3.1 won't take it (FIT_HOME=%FIT_HOME%). I don't want to have to duplicate the value for obvious reasons. Basically I want an environment variable to propagate into the Eclipse settings "automagically" if possible. If not possible, then I want to manually define it, binding to the environment variable itself instead of duplicating the value. I want to zip up a pre-configured Worspace and distribute to a group and know that they can checkout a project that has a .classpath file which refers to FIT_HOME (and others) and not have problems with the build. I want it to build properly. I want the FIT_HOME var in Eclipse to work for them regardless of what the actual value of the env var FIT_HOME is. Another possibility is to make use of the env var FIT_HOME in the .classpath file instead of the eclipse var FIT_HOME. Does that work? %FIT_HOME% ? Is that cross-platform? I have tried the following Eclipse shortcut but that also fails to populate the Eclipse variables with FIT_HOME: C:\eclipse3.1\eclipse.exe -data C:\marcio\workspace -vm "C:\Program Files\Java\jdk1.5.0_05\bin\javaw.exe" -vmargs -DFIT_HOME=%FIT_HOME% -Xmx268000000
Classpath variables don't support this. Moving to jdt.core. I think for 3.3 we should discuss about how to continue with classpath variables. Maye we find a way to merge with org.eclipse.core.variables.
This can be achieved by a ClasspathVariableInitializer that would set the classpath variable to the corresponding environment variable value. Moving to JDT Debug for consideration since debug.core as the code to read environment variables.
A related suggestion: *_HOME vars should automatically make it into Eclipse. Java has many components that follow this approach: JAVA_HOME ANT_HOME CATALINA_HOME ... If there isn't an override present in Eclipse, it should take the values from the env vars and make them available inside Eclipse.
Martin, this could be done with a special "environment" classpath variable that gets extended in a custom way - i.e. with an environment variable name and optional path extension. However, the "Extend..." UI for classpath variables is not currently extensible.
But wouldn't we still need classpath variable initializers? These have to be contributed for a specific variable name. How would that work? I assume you want the user can choose a env variable that is now also a classpath variable. Did I miss something?
Ah right... we don't get a chance to resolve the "extension" to a classpath variable - it's just a path. I'd say this is not really possible with current classpath variables. It might be possibe with a classpath container - it gets to resolve dynamically and can have secondary "paths" that are interpretted by the contributor.
*** Bug 156745 has been marked as a duplicate of this bug. ***
We don't have the resources to do this in 3.3, but I believe it could be contributed by any component using existing API. A ne classpath container would need to be defined. Each instance of the container would be associated with an evnrionment variable. The container would resolve to the libaries associated with the variable. A wizard page could be contributed to JUI's org.eclipse.jdt.ui.classpathContainerPage extension point, to configure the container. For now, I'm marking as LATER.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
