| <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> | |
| <html> | |
| <head> | |
| <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> | |
| </head> | |
| <body> | |
| <h2> | |
| 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. | |
| <h3> | |
| Proposal</h3> | |
| 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 | |
| variables. | |
| <p>Examples of how this would be used: | |
| <p><tt><extension</tt> | |
| <br><tt> point = "org.eclipse.jdt.core.classpathVariableInitializer"></tt> | |
| <br><tt> <classpathVariableInitializer</tt> | |
| <br><tt> variable="ECLIPSE_HOME"</tt> | |
| <br><tt> class="org.eclipse.pde.internal.core.EclipseHomeInitializer"/></tt> | |
| <br><tt></extension></tt> | |
| <p><tt><extension</tt> | |
| <br><tt> point = "org.eclipse.jdt.core.classpathVariableInitializer"></tt> | |
| <br><tt> <classpathVariableInitializer</tt> | |
| <br><tt> variable="JRE_LIB"</tt> | |
| <br><tt> class="org.eclipse.jdt.internal.ui.CPVInitializer"/></tt> | |
| <br><tt></extension></tt> | |
| <p>The mechanism would work as follows: | |
| <ul> | |
| <li> | |
| It applies automatically each time a classpath containing an unbound classpath | |
| variable is being resolved (e.g., by JavaCore.getResolvedClasspathEntry | |
| or IJavaProject.getResolvedClasspath).</li> | |
| <li> | |
| If classpath variable is unbound in the workspace, it ask if there is a | |
| registered initializer for that variable.</li> | |
| <li> | |
| If there is an initializer, it is invoked (it is passed the name of the | |
| classpath variable that needs to be initialized).</li> | |
| <li> | |
| The initializer returns no result; it simply has the side effect initializing | |
| the variable if it can.</li> | |
| <li> | |
| After the initializer is invoked, the resolution process proceeds whether | |
| or not the variable is bound or unbound.</li> | |
| <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> | |
| </ul> | |
| </body> | |
| </html> |