blob: 58cfa37b192e92f771a90bf6c1fb190c095c63d7 [file] [log] [blame]
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.5 [en] (Win98; I) [Netscape]">
<title>JDT - Uninitialized Classpath Variables</title>
Uninitialized Classpath Variables</h2>
Last revised 11:30 Monday November 19, 2001
<p>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."
<p>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.
<p>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.
<p>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.
<p>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 <tt><a href="classpathVariableInitializer.html">org.eclipse.jdt.core.classpathVariableInitializer</a></tt>
through which plug-ins can supply initializer code for named classpath
<p>Examples of how this would be used:
<br><tt>&nbsp;&nbsp;&nbsp; point = "org.eclipse.jdt.core.classpathVariableInitializer"></tt>
<br><tt>&nbsp;&nbsp;&nbsp; &lt;classpathVariableInitializer</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; variable="ECLIPSE_HOME"</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; class="org.eclipse.pde.internal.core.EclipseHomeInitializer"/></tt>
<br><tt>&nbsp;&nbsp;&nbsp; point = "org.eclipse.jdt.core.classpathVariableInitializer"></tt>
<br><tt>&nbsp;&nbsp;&nbsp; &lt;classpathVariableInitializer</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; variable="JRE_LIB"</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; class="org.eclipse.jdt.internal.ui.CPVInitializer"/></tt>
<p>The mechanism would work as follows:
It applies automatically each time a classpath containing an unbound classpath
variable is being resolved (e.g., by JavaCore.getResolvedClasspathEntry
or IJavaProject.getResolvedClasspath).</li>
If classpath variable is unbound in the workspace, it ask if there is a
registered initializer for that variable.</li>
If there is an initializer, it is invoked (it is passed the name of the
classpath variable that needs to be initialized).</li>
The initializer returns no result; it simply has the side effect initializing
the variable if it can.</li>
After the initializer is invoked, the resolution process proceeds whether
or not the variable is bound or unbound.</li>
If there are multiple initializers registered for the same variable, only
the first one is used (this mechanims does not support alternate or hierarchical
classpath variable initializers).</li>