[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[jdt-core-dev] extension point for initializing unbound classpath variables
|
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).