Attachment 170165 Details for Bug 313890 – Fix 7

[patch] Fix 7

313890_patch7.txt (text/plain), 6.47 KB, created by Markus Keller

on 2010-05-27 06:47:21 EDT

(hide)

Description:

Filename:

MIME Type:

Creator: Markus Keller

Created: 2010-05-27 06:47:21 EDT

Size: 6.47 KB

patch

obsolete

>### 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	27 May 2010 10:45:20 -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> 
>+ * A library entry can reference other libraries through the Class-Path section of the JAR's MANIFEST.MF file. If the
>+ * container wants such referenced entries to be part of the classpath, the container must explicitly add them to the
>+ * array returned from {@link #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>
>@@ -63,7 +67,10 @@
> 	 * </ul>
> 	 * A classpath container can neither reference further classpath containers
> 	 * or classpath variables.
>-	 * </p>
>+	 * <p>
>+	 * A library entry can reference other libraries through the Class-Path section of the JAR's MANIFEST.MF file. If
>+	 * the container wants such referenced entries to be part of the classpath, the container must explicitly add them
>+	 * to the result.
> 	 * <p>
> 	 * This method is called by the Java model when it needs to resolve this
> 	 * classpath container entry into a list of library and project entries.
>@@ -80,6 +87,7 @@
> 	 * <li>{@link JavaCore#newProjectEntry(IPath, boolean)} and variants</li>
> 	 * <li>{@link JavaCore#create(org.eclipse.core.resources.IWorkspaceRoot)}</li>
> 	 * <li>{@link JavaCore#create(org.eclipse.core.resources.IProject)}</li>
>+	 * <li>{@link JavaCore#getReferencedClasspathEntries(IClasspathEntry, IJavaProject)} with <code>null</code> as project</li>
> 	 * <li>{@link IJavaModel#getJavaProjects()}</li>
> 	 * <li>{@link IJavaProject#getRawClasspath()}</li>
> 	 * <li>{@link IJavaProject#readRawClasspath()}</li>
>#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.7
>diff -u -r1.7 incompatibilities.html
>--- porting/3.6/incompatibilities.html	25 May 2010 15:46:57 -0000	1.7
>+++ porting/3.6/incompatibilities.html	27 May 2010 10:45:21 -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">Classpath containers have the choice to resolve the referenced libraries themselves</a></li>  
> </ol>
> 
> <hr>
>@@ -74,6 +75,23 @@
> private List l;
> </pre>
> 
>+<h2>4. <a name="ReferencedLibraries">Classpath containers have the choice to resolve the referenced libraries themselves</a></h2>
>+<p><strong>What is affected:</strong> Classpath containers that depended on JDT to resolve referenced libraries via JAR's MANIFEST.MF.</p>
>+<p><strong>Description:</strong> 
>+In 3.5, classpath containers did not have full control over what JARs ended up on the classpath, since references in the Class-Path section 
>+of a JAR's MANIFEST.MF were automatically added. In 3.6, referenced JARs are not automatically added any more. However, a classpath container 
>+implementor can use <code>JavaCore#getReferencedClasspathEntries()</code> to resolve the referenced JARs and return them in the implementation of 
>+<code>IClasspathContainer#getClasspathEntries()</code>.</p>
>+<p>Please refer to the documentation of these APIs:<br>
>+<ul>
>+<li><code>IClasspathContainer</code></li>
>+<li><code>JavaCore#getReferencedClasspathEntries()</code></li>
>+</ul>
>+<p><strong>Action required:</strong> 
>+If the classpath container implementation cannot be changed to accommodate this, the 3.5 behavior can be retained by adding a system property (<code>-DresolveReferencedLibrariesForContainers=true</code>) to the <code>-vmargs</code>
>+list on start-up.</p> 
>+
>+
> 
> </body>
> </html>
>#P org.eclipse.platform-feature
>Index: rootfiles/readme/readme_eclipse.html
>===================================================================
>RCS file: /cvsroot/eclipse/org.eclipse.platform-feature/rootfiles/readme/readme_eclipse.html,v
>retrieving revision 1.133
>diff -u -r1.133 readme_eclipse.html
>--- rootfiles/readme/readme_eclipse.html	26 May 2010 12:43:07 -0000	1.133
>+++ rootfiles/readme/readme_eclipse.html	27 May 2010 10:45:22 -0000
>@@ -1484,8 +1484,15 @@
> after you've upgraded your workspace, you won't be able to use it
> again with an older version of Eclipse. If you ever want to go &quot;back in
> time&quot; to an earlier release, you will need that backup.</p>
>-
>-
>+<h3> Users who use User Libraries or classpath containers that contain JARs referencing other libraries via Class-Path in the MANIFEST.MF</h3>
>+<p>
>+If you want the referenced JAR files to be included in the classpath, you can do one of the following:<br>
>+<ul>
>+<li>Add the system property (<code>-DresolveReferencedLibrariesForContainers=true</code>) to the <code>-vmargs</code>
>+list on start-up, or
>+<li>Manually add the referenced JARs to the User Library or to the project.
>+</ul>
>+</p>
> <h2>6. <a name="Interoperability with Previous Releases">Interoperability with
> Previous Releases</a></h2>
> <h3>6.1 Interoperability of Release 3.5 with previous releases</h3>

Actions: View | Diff

Attachments on bug 313890: 169638 | 169852 | 170020 | 170062 | 170087 | 170163 | 170164 | 170165