### Eclipse Workspace Patch 1.0
#P org.eclipse.jdt.core
Index: model/org/eclipse/jdt/core/IClasspathContainer.java
===================================================================
RCS file: /cvsroot/eclipse/org.eclipse.jdt.core/model/org/eclipse/jdt/core/IClasspathContainer.java,v
retrieving revision 1.24
diff -u -r1.24 IClasspathContainer.java
--- model/org/eclipse/jdt/core/IClasspathContainer.java	7 Mar 2009 01:08:10 -0000	1.24
+++ model/org/eclipse/jdt/core/IClasspathContainer.java	24 May 2010 07:48:30 -0000
@@ -1,5 +1,5 @@
 /*******************************************************************************
- * Copyright (c) 2000, 2009 IBM Corporation and others.
+ * Copyright (c) 2000, 2010 IBM Corporation and others.
  * All rights reserved. This program and the accompanying materials
  * are made available under the terms of the Eclipse Public License v1.0
  * which accompanies this distribution, and is available at
@@ -27,6 +27,10 @@
  * <li> project entries (<code>CPE_PROJECT</code>) </li>
  * </ul>
  * In particular, a classpath container can neither reference further classpath containers or classpath variables.
+ * <p> 
+ * It is possible that the library entries (that are JAR files) can further reference other libraries through the
+ * Class-Path section of the MANIFEST.MF file. If the container wants such referenced entries to be 
+ * part of the classpath, they must be provided via {@link IClasspathContainer#getClasspathEntries()}.
  * <p>
  * Classpath container values are persisted locally to the workspace, but are not preserved from a
  * session to another. It is thus highly recommended to register a <code>ClasspathContainerInitializer</code>
@@ -61,8 +65,9 @@
 	 * <li> library entries (<code>CPE_LIBRARY</code>) </li>
 	 * <li> project entries (<code>CPE_PROJECT</code>) </li>
 	 * </ul>
-	 * A classpath container can neither reference further classpath containers
-	 * or classpath variables.
+	 * The set may include the library entries that are referenced via the MANIFEST.MF file.
+	 * However, a classpath container can neither reference further classpath containers
+	 * or classpath variables. 
 	 * </p>
 	 * <p>
 	 * This method is called by the Java model when it needs to resolve this
#P org.eclipse.jdt.doc.isv
Index: porting/3.6/incompatibilities.html
===================================================================
RCS file: /cvsroot/eclipse/org.eclipse.jdt.doc.isv/porting/3.6/incompatibilities.html,v
retrieving revision 1.6
diff -u -r1.6 incompatibilities.html
--- porting/3.6/incompatibilities.html	19 May 2010 12:27:00 -0000	1.6
+++ porting/3.6/incompatibilities.html	24 May 2010 07:48:35 -0000
@@ -21,6 +21,7 @@
   <li><a href="#JUnit4">SDK ships 2 org.junit plug-ins (versions 3.8.2 and 4.8.1)</a></li>
   <li><a href="#AbstractTemplatesPage">Source incompatibility for subclasses of <code>AbstractTemplatesPage</code></a></li>
   <li><a href="#SuppressWarningRawTypes"><code>@SuppressWarnings("unchecked")</code> does not ignore raw types warnings anymore</a></li>
+  <li><a href="#ReferencedLibraries">Class-Path references via MANIFEST.MF are not resolved automatically for containers</a></li>
 </ol>
 
 <hr>
@@ -75,5 +76,20 @@
 </pre>
 <!-- ############################################## -->
 
+<h2>4. <a name="ReferencedLibraries">Class-Path references via MANIFEST.MF are not resolved automatically for containers</a></h2>
+
+<p><strong>What is affected:</strong> Classpath containers (implementors of IClasspathContainer) that depend on JDT to resolve referenced libraries via MANIFEST.MF.</p>
+
+<p><strong>Description:</strong> When a JAR file declares other libraries in the Class-Path section of the MANIFEST.MF, JDT resolves and automatically includes the referenced libraries in the project's classpath. From 3.6, JDT no longer resolves such referenced libraries for classpath containers. In other words, if a container has libraries referencing other libraries (that are not directly part of classpath already), the referenced ones will not added to the project's classpath. This could result in projects that compiled well in 3.5 seeing compilation errors in 3.6.</p>
+
+<p><strong>Action required:</strong> If a container wants referenced libraries to be part of a project's classpath, the container must do it themselves . The containers could do this by altering the implementation of IClasspathContainer#getClasspathEntries to include the referenced libraries. The containers can use JavaCore#getReferencedClasspathEntries() to get the list of referenced libraries for each library they contain.</p> 
+
+<p>Please refer to the Javadoc of the following sections for further reference:<br>
+<ol><code>
+<li>IClasspathContainer<br></li>
+<li>JavaCore#getReferencedClasspathEntries()</li>
+</code></ol>
+</p>
+<!-- ############################################## -->
 </body>
 </html>