Classpath Variable Initializer

["Jim des Rivieres/OTT/OTI" <Jim_des_Rivieres@xxxxxxx>]

Attached is a proposal for a new JDT core extension point that would allow
a plug-in to
declare that it is responsible for initializing a particular classpath
variable.



Doc for the new API class and extension point:



Please send comments and questions to this mailing list.

---jeem
(See attached file: ClasspathVariableInitializer.java)
(See attached file: classpathVariableInitializer.html)
(See attached file: uninit-classpath-vars.html)

Attachment: ClasspathVariableInitializer.java
Description: Binary data

Title: Workbench Extension Point - Classpath Variable Initializer

Classpath Variable Initializer

Identifier: org.eclipse.jdt.core.classpathVariableInitializer

Description: This extension point allows a plug-in to register code for programmatically initializing a particular named classpath variable.

Configuration Markup:

   <!ELEMENT classpathVariableInitializer>
   <!ATTLIST classpathVariableInitializer
      variable   CDATA #REQUIRED
      class      CDATA #REQUIRED
   >

• variable - the name of the classpath variable
• class - the class that implements this classpath variable initializer. The class must implement a public subclass of org.eclipse.jdt.core.ClasspathVariableInitializer with a public 0-argument constructor and an implementation of the initialize(String) method.

Examples:
The following is an example of an IClasspathVariableInitializer for a classpath variable named "FOO":

<extension
      point="org.eclipse.jdt.core.classpathVariableInitializer">
   <classpathVariableInitializer
         variable="FOO"
         class="com.example.CPVInitializer"/>
</extension>

Supplied Implementation:
None.
 

Title: JDT - Uninitialized Classpath Variables

Uninitialized Classpath Variables

Last revised 11:30 Monday November 19, 2001

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.

Proposal

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:

• It applies automatically each time a classpath containing an unbound classpath variable is being resolved (e.g., by JavaCore.getResolvedClasspathEntry or IJavaProject.getResolvedClasspath).
• If classpath variable is unbound in the workspace, it ask if there is a registered initializer for that variable.
• If there is an initializer, it is invoked (it is passed the name of the classpath variable that needs to be initialized).
• The initializer returns no result; it simply has the side effect initializing the variable if it can.
• After the initializer is invoked, the resolution process proceeds whether or not the variable is bound or unbound.
• 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).