*** empty log message ***
diff --git a/org.eclipse.jdt.core/model/org/eclipse/jdt/core/JavaCore.java b/org.eclipse.jdt.core/model/org/eclipse/jdt/core/JavaCore.java
index e7f6bdf..a8c31a4 100644
--- a/org.eclipse.jdt.core/model/org/eclipse/jdt/core/JavaCore.java
+++ b/org.eclipse.jdt.core/model/org/eclipse/jdt/core/JavaCore.java
@@ -141,10 +141,35 @@
attributes.put(ATT_HANDLE_ID, element.getHandleIdentifier());
}
- /** TOFIX
+ /**
+ * Notification of a classpath container change. This notification must be performed
+ * by client code which did register some classpath container resolvers, whenever
+ * changes in container need to be reflected onto the JavaModel.
+ * <p>
+ * In reaction to this notification, the JavaModel will be updated to reflect the new
+ * state of the updated container. Note that the update can be scoped to either
+ * a given project or the entire Java model according to the changeScope argument.
+ * This is symetric to container resolution which enables project specific resolution.
+ * <p>
+ * This functionality cannot be used while the resource tree is locked.
+ * <p>
+ * Classpath container states are persisted locally to the workspace, and
+ * are preserved from session to session.
+ * <p>
+ * When notifying a container change, the corresponding container resolver should
+ * in turn expect to be activated so as to resolve the updated container path.
*
+ * @param containerPath - the name of the container which is being updated
+ * @param changeScope - the scope of the change, either a specific project (IJavaProject)
+ * or the entire JavaModel (IJavaModel).
+ * @param monitor a monitor to report progress
+ *
+ * @see #getResolvedClasspathContainer(IPath, IJavaProject)
+ * @since 2.0
*/
- public void classpathContainerChanged(IPath containerPath, IJavaProject project){
+ public void classpathContainerChanged(IPath containerPath, IJavaElement changeScope, IProgressMonitor monitor){
+
+ //TOFIX
}
/**
@@ -424,6 +449,12 @@
* </ul>
* A classpath container cannot reference further classpath containers.
* <p>
+ * @param containerPath - the name of the container which needs to be resolved
+ * @param changeScope - a specific project (IJavaProject) in which the container is being resolved
+ *
+ * @exception JavaModelException if an exception occurred while resolving the container, or if the resolved container
+ * contains illegal entries (further container entries or null entries).
+ *
* @since 2.0
*/
public static IClasspathEntry[] getResolvedClasspathContainer(IPath containerPath, IJavaProject project) throws JavaModelException {
@@ -440,6 +471,7 @@
ClasspathContainerResolver resolver = JavaModelManager.getClasspathContainerResolver(containerPath);
if (resolver != null){
projectContainers.put(containerPath, JavaModelManager.ContainerInitializationInProgress); // avoid initialization cycles
+ boolean ok = false;
try {
entries = resolver.resolve(containerPath, project);
@@ -448,7 +480,6 @@
for (int i = 0; i < entries.length; i++){
IClasspathEntry entry = entries[i];
if (entry == null || entry.getEntryKind() == IClasspathEntry.CPE_CONTAINER){
- JavaModelManager.Containers.put(project, null); // flush cache
throw new JavaModelException(
new JavaModelStatus(
IJavaModelStatusConstants.INVALID_CP_CONTAINER_ENTRY,
@@ -456,10 +487,11 @@
}
}
}
-
+ ok = true;
} catch(CoreException e){
- JavaModelManager.Containers.put(project, null); // flush cache
throw new JavaModelException(e);
+ } finally {
+ if (!ok) JavaModelManager.Containers.put(project, null); // flush cache
}
if (entries != null){
projectContainers.put(containerPath, entries);
diff --git a/org.eclipse.jdt.core/notes/r2.0/classpath container/classpathContainer.htm b/org.eclipse.jdt.core/notes/r2.0/classpath container/classpathContainer.htm
new file mode 100644
index 0000000..e3e6403
--- /dev/null
+++ b/org.eclipse.jdt.core/notes/r2.0/classpath container/classpathContainer.htm
@@ -0,0 +1,239 @@
+<!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 http-equiv="Content-Language" content="en-us">
+ <meta name="GENERATOR" content="Microsoft FrontPage 4.0">
+ <meta name="ProgId" content="FrontPage.Editor.Document">
+ <title>Class Path Container Enhancement</title>
+</head>
+<body>
+
+<h1>Class Path Container Enhancement</h1>
+<span style="FONT-SIZE: 10pt">Last Modified April 23, 2002</span>
+
+
+<h2>
+Background</h2>
+JDT supports to switch the JDK that is used for building. It is currently
+implemented as follows:
+<ul>
+<li>
+org.eclipse.jdt.launching maintains the following JDK/VM information in
+its plugin metadata:</li>
+
+<ul>
+<li>
+a set of <i>VM install types</i>: a description of a VM install. It knows
+how to find the location of the binary JAR and the source JARs.</li>
+
+<li>
+<i>VM installs: </i>the location/home of a VM install on the file system.
+A VM install has an internal ID that is not visible to the user.</li>
+
+<li>
+one of the VM installs is marked as the <i>default VM install</i>.</li>
+</ul>
+
+<li>
+org.eclipse.jdt.launching defines a JRE_LIB, JRE_SRC, JRE_SRCROOT variables
+that binds to the default VM install:</li>
+
+<ul>
+<li>
+JRE_LIB: the binary JAR (e.g. rt.jar)</li>
+
+<li>
+JRE_SRC: the source JAR/zip (e.g. src.jar)</li>
+
+<li>
+JRE_SRCROOT: the prefix in the source JAR (e.g. "src")</li>
+</ul>
+
+<li>
+The Java project creation wizard adds a JRE_LIB classpath variable on a
+project's build class path.</li>
+
+<li>
+org.eclipse.jdt.debug.ui contributes a preference page to define new VM
+installs and to set the default VM install. When the default VM install
+changes, then the bindings of the JRE_* variables are changed accordingly.</li>
+
+<li>
+org.eclipse.jdt.ui contributes a class path variable preference page. It
+"knows" that the JRE_* variables are reserved and doesn't allow the user
+to edit them.</li>
+
+<li>
+The packages view shows the resolved JRE_LIB contents as a referenced library.</li>
+</ul>
+Characteristics of the current implementation:
+<ul>
+<li>
+Class path stability: changing the default JRE/VM install doesn't affect
+the build class path since the JRE_LIB variable is not affected by this
+change. In other words, when a user changes the JRE for building then the
+.classpath file is not affected.</li>
+
+<li>
+JDK switching at the workspace level for all projects is straightforward
+by the user, only the default VM install needs to be changed and all projects
+in the workspace switch to use this VM install.</li>
+
+<li>
+Since class path variables can only bind to a single JAR, the JRE_LIB variable
+can only bind to a single JAR (for the standard SUN JRE this is rt.jar).</li>
+
+<li>
+There is some magic involved with regard to the handling of JRE_* variables
+that is not obvious to the user:</li>
+
+<ul>
+<li>
+on the build class path the user sees JRE_LIB but when defining a launch
+configuration then the user sees VM Installs. The user has to know that
+JRE_LIB is indirectly bound to the VM install via the JRE installed preference
+settings.</li>
+
+<li>
+The user also has to understand that the reserved variables cannot be edited
+like the other class path variables, etc.</li>
+</ul>
+
+<li>
+Build class path ordering - users can control the order of the build class
+path in a simple way. For example, to do JCL development, to do so users
+can put their source folders in front of the JRE_LIB class path entry.</li>
+
+<li>
+Java Core is not affected by the JDK switching support and is independent
+of launching concerns.</li>
+</ul>
+
+<h2>
+Motivation for enhancing the current implementation</h2>
+
+<h3>
+New Requirements</h3>
+There are new requirements with regard to the handling of the JRE/JDK on
+the build class path that need to be addressed by 2.0:
+<ul>
+<li>
+Multiple JARs per JDK</li>
+
+<br>The JRE_LIB class path variable can only bind to a single JAR file
+typically the rt.jar. However, there are JDK installs that have split the
+rt.jar into multiple JARs. For example, the JDK on the MacOS X has split
+the rt.jar into: classes.jar and ui.jar (contains AWT and Swing).
+<br>
+<li>
+Workspaces with a different JDK per project</li>
+
+<br>WSDD needs support for having a workspace where different projects
+build against different JDKs. The JRE_LIB variable is global and there
+is no infrastructure and UI support to have different JDKs for different
+projects. WSDD defined their own build description mechanism that bypasses
+the JRE_LIB support. This results in a problematic user experience when
+switching from WSAD or vanilla Eclipse Java development to WSDD.</ul>
+
+<h3>
+Existing characteristics to be preserved in the new implementation</h3>
+
+<ul>
+<li>
+Class path stability, it has to be possible to switch a JDK locally in
+a workspace without affecting the .classpath file.</li>
+
+<li>
+Easy JDK switching at the workspace level, i.e., a single setting can be
+changed to change the build class path of all projects.</li>
+
+<li>
+Java Core is independent of the VM install infrastructure</li>
+</ul>
+
+<h2>
+Proposal</h2>
+The proposal affects core, launching, java debug UI, and the Java UI components.
+<h3>
+JavaCore</h3>
+JavaCore provides a new type of classpath entry "CPE_CONTAINER",
+which is just a named reference to a set of other classpath entries.
+A container entry refers to a container path, which will be resolved by
+a <code>ClasspathContainerResolver</code> through an extension point.
+
+The actual binding from the CPE_Container entry to
+the target classpath entries is implemented in term of an extension point
+to keep Java Core independent of VM install concerns:
+<p><tt> <!ELEMENT classpathContainerResolver
+EMPTY></tt>
+<br><tt> <!ATTLIST classpathContainerResolver</tt>
+<br><tt> prefix
+CDATA #REQUIRED</tt>
+<br><tt> class
+CDATA #REQUIRED</tt>
+<br><tt> ></tt>
+<ul>
+<li><b>prefix</b> - the prefix of container names for which this resolver will be activated.</li>
+<li><b>class</b> - the class that implements this container resolver.
+The class must implement a public subclass of <code>org.eclipse.jdt.core.ClasspathContainerResolver</code>
+with a public 0-argument constructor.</li>
+</ul>
+<tt> abstract class ClasspathContainerResolver
+{</tt>
+<br><tt>
+IClasspathEntry[] resolve(IPath containerPath, IJavaProject project) throws
+CoreException;</tt>
+<br> }
+<p>The resolve call passes in a project, this enables
+to resolve a class path in the context of a particular project.
+The resolve method should only be called once to resolve the class path
+entry (in case of failure, the container will not be considered as having been
+resolved).
+
+<p>It is possible to register a resolved per
+container path prefix, the full container path being passed along to the resolver
+so as to provide additional hints for the container expansion.
+In case multiple resolvers are registered, the one with the longest prefix match
+will be invoked to resolve a given container path (in case of ambiguity, the first
+registered one will be used).
+
+<p>JavaCore provides a method to signal JDT/Core that a container definition
+was changed.
+<ul>
+<li><code>JavaCore#containerChanged(IPath containerPath, IJavaElement scope)</code>.
+</ul>
+The scope can either refer to a particular project or the entire JavaModel. In reaction
+to invoking this method, the JavaModel will be refreshed and corresponding Java element
+changes will be notified.
+
+<p><font color="#FF0000"><b>Issue</b>: The Mac OS X JDK install is
+an interesting case. There the rt.jar is split into two binary JARs (classes.jar,
+ui.jar), but there is still a single src.jar. This cases needs to be handled by </font><font color="#FF0000">the
+source lookup. For example, when src.jar is attached to classes.jar then when
+looking up java.awt.Frame out of ui.jar, the source attachment of classes.jar
+needs to searched as well.</font>
+
+<h2>
+Example</h2>
+The class path of a project will look as follows:
+<p>
+<classpath>
+<br>
+<classpathentry kind="src" path="/src"/>
+<br>
+<classpathentry kind="container" path="JDK/1.3"/>
+<br>
+<classpathentry kind="output" path="bin"/>
+<br>
+</classpath>
+<p>In the case where the user didn't override the
+VM install at the project level. Then the Java launching contributed container
+resolver (registered for container prefixes: "JDK") would resolve "JDK/1.3" using the default
+VM install, using "1.3" as an hint, and may expand it into the following:
+<p>
+<classpathentry kind="lib" path="d:/jdk/1.3.1/jre/lib/rt.jar"
+rootpath="d:/jdk1.3.1/lib/src.jar" sourcepath="/src"/>
+
+</body>
+</html>
