| <!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> |
| <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> |
| <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> |
| <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> |
| <p>This problem is a symptom of a more widespread problem. For example, |
| PDE suffers this problem with the "ECLIPSE_HOME" variable.</p> |
| <h3> |
| Proposal</h3> |
| <p>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> |
| <p>Examples of how this would be used:</p> |
| <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> |
| <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> |
| <p>The mechanism would work as follows:</p> |
| <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> |
