Original work item: "Building with uninitialized class path variables. You can add a project from the repository that gets built without having the JavaUI that initializes the JRE_ variables is activated."
The general problem is that a classpath variable can show up in a project's classpath quite early (for example, when a project is loaded from a repository), and well before the activation of a plug-in that might willingly initialize the workspace's binding for that variable. Without a binding for all the variables mentioned on its build classpath, the project cannot be successfully built. However, there is currently no mechanism by which these variables can get initialized.
For variables that the developer (or his team mates) introduces explicitly, this is not a particular problem. The developer's corrective action is to explicitly establish a binding for the variable, and then rebuild.
However, there is a problem for variables that are introduced and ordinalrily initialized by some tool. For these, the developer may not be in a position to explicitly establish a binding for the variable, and might not even know which plug-in needs to be activated.
This problem is a symptom of a more widespread problem. For example, PDE suffers this problem with the "ECLIPSE_HOME" variable.
We introduce a JDT Core extension point org.eclipse.jdt.core.classpathVariableInitializer through which plug-ins can supply initializer code for named classpath variables.
Examples of how this would be used:
<extension
point = "org.eclipse.jdt.core.classpathVariableInitializer">
<classpathVariableInitializer
variable="ECLIPSE_HOME"
class="org.eclipse.pde.internal.core.EclipseHomeInitializer"/>
</extension>
<extension
point = "org.eclipse.jdt.core.classpathVariableInitializer">
<classpathVariableInitializer
variable="JRE_LIB"
class="org.eclipse.jdt.internal.ui.CPVInitializer"/>
</extension>
The mechanism would work as follows: