Attachment #170165 for bug #313890

Lines 1-5 Link Here

(-)model/org/eclipse/jdt/core/IClasspathContainer.java (-2 / +10 lines)
1	/*******************************************************************************	1	/*******************************************************************************
2	* Copyright (c) 2000, 2009 IBM Corporation and others.	2	* Copyright (c) 2000, 2010 IBM Corporation and others.
3	* All rights reserved. This program and the accompanying materials	3	* All rights reserved. This program and the accompanying materials
4	* are made available under the terms of the Eclipse Public License v1.0	4	* are made available under the terms of the Eclipse Public License v1.0
5	* which accompanies this distribution, and is available at	5	* which accompanies this distribution, and is available at
Lines 27-32 Link Here
27	* <li> project entries (<code>CPE_PROJECT</code>) </li>	27	* <li> project entries (<code>CPE_PROJECT</code>) </li>
28	* </ul>	28	* </ul>
29	* In particular, a classpath container can neither reference further classpath containers or classpath variables.	29	* In particular, a classpath container can neither reference further classpath containers or classpath variables.
		30	* <p>
		31	* A library entry can reference other libraries through the Class-Path section of the JAR's MANIFEST.MF file. If the
		32	* container wants such referenced entries to be part of the classpath, the container must explicitly add them to the
		33	* array returned from {@link #getClasspathEntries()}.
30	* <p>	34	* <p>
31	* Classpath container values are persisted locally to the workspace, but are not preserved from a	35	* Classpath container values are persisted locally to the workspace, but are not preserved from a
32	* session to another. It is thus highly recommended to register a <code>ClasspathContainerInitializer</code>	36	* session to another. It is thus highly recommended to register a <code>ClasspathContainerInitializer</code>
Lines 63-69 Link Here
63	* </ul>	67	* </ul>
64	* A classpath container can neither reference further classpath containers	68	* A classpath container can neither reference further classpath containers
65	* or classpath variables.	69	* or classpath variables.
66	* </p>	70	* <p>
		71	* A library entry can reference other libraries through the Class-Path section of the JAR's MANIFEST.MF file. If
		72	* the container wants such referenced entries to be part of the classpath, the container must explicitly add them
		73	* to the result.
67	* <p>	74	* <p>
68	* This method is called by the Java model when it needs to resolve this	75	* This method is called by the Java model when it needs to resolve this
69	* classpath container entry into a list of library and project entries.	76	* classpath container entry into a list of library and project entries.
Lines 80-85 Link Here
80	* <li>{@link JavaCore#newProjectEntry(IPath, boolean)} and variants</li>	87	* <li>{@link JavaCore#newProjectEntry(IPath, boolean)} and variants</li>
81	* <li>{@link JavaCore#create(org.eclipse.core.resources.IWorkspaceRoot)}</li>	88	* <li>{@link JavaCore#create(org.eclipse.core.resources.IWorkspaceRoot)}</li>
82	* <li>{@link JavaCore#create(org.eclipse.core.resources.IProject)}</li>	89	* <li>{@link JavaCore#create(org.eclipse.core.resources.IProject)}</li>
		90	* <li>{@link JavaCore#getReferencedClasspathEntries(IClasspathEntry, IJavaProject)} with <code>null</code> as project</li>
83	* <li>{@link IJavaModel#getJavaProjects()}</li>	91	* <li>{@link IJavaModel#getJavaProjects()}</li>
84	* <li>{@link IJavaProject#getRawClasspath()}</li>	92	* <li>{@link IJavaProject#getRawClasspath()}</li>
85	* <li>{@link IJavaProject#readRawClasspath()}</li>	93	* <li>{@link IJavaProject#readRawClasspath()}</li>




  <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>

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>

Lines 1484-1491 Link Here

(-)rootfiles/readme/readme_eclipse.html (-2 / +9 lines)
1484	after you've upgraded your workspace, you won't be able to use it	1484	after you've upgraded your workspace, you won't be able to use it
1485	again with an older version of Eclipse. If you ever want to go "back in	1485	again with an older version of Eclipse. If you ever want to go "back in
1486	time" to an earlier release, you will need that backup.</p>	1486	time" to an earlier release, you will need that backup.</p>
1487		1487	<h3> Users who use User Libraries or classpath containers that contain JARs referencing other libraries via Class-Path in the MANIFEST.MF</h3>
1488		1488	<p>
		1489	If you want the referenced JAR files to be included in the classpath, you can do one of the following:<br>
		1490	<ul>
		1491	<li>Add the system property (<code>-DresolveReferencedLibrariesForContainers=true</code>) to the <code>-vmargs</code>
		1492	list on start-up, or
		1493	<li>Manually add the referenced JARs to the User Library or to the project.
		1494	</ul>
		1495	</p>
1489	<h2>6. <a name="Interoperability with Previous Releases">Interoperability with	1496	<h2>6. <a name="Interoperability with Previous Releases">Interoperability with
1490	Previous Releases</a></h2>	1497	Previous Releases</a></h2>
1491	<h3>6.1 Interoperability of Release 3.5 with previous releases</h3>	1498	<h3>6.1 Interoperability of Release 3.5 with previous releases</h3>

Return to bug 313890

Lines 21-26 Link Here

(-)porting/3.6/incompatibilities.html (+18 lines)
21	<li><a href="#JUnit4">SDK ships 2 org.junit plug-ins (versions 3.8.2 and 4.8.1)</a></li>	21	<li><a href="#JUnit4">SDK ships 2 org.junit plug-ins (versions 3.8.2 and 4.8.1)</a></li>
22	<li><a href="#AbstractTemplatesPage">Source incompatibility for subclasses of <code>AbstractTemplatesPage</code></a></li>	22	<li><a href="#AbstractTemplatesPage">Source incompatibility for subclasses of <code>AbstractTemplatesPage</code></a></li>
23	<li><a href="#SuppressWarningRawTypes"><code>@SuppressWarnings("unchecked")</code> does not ignore raw types warnings anymore</a></li>	23	<li><a href="#SuppressWarningRawTypes"><code>@SuppressWarnings("unchecked")</code> does not ignore raw types warnings anymore</a></li>
		24	<li><a href="#ReferencedLibraries">Classpath containers have the choice to resolve the referenced libraries themselves</a></li>
24	</ol>	25	</ol>
25		26
26	<hr>	27	<hr>
Lines 74-79 Link Here
74	private List l;	75	private List l;
75	</pre>	76	</pre>
76	<!-- ############################################## -->	77	<!-- ############################################## -->
		78	<h2>4. <a name="ReferencedLibraries">Classpath containers have the choice to resolve the referenced libraries themselves</a></h2>
		79	<p><strong>What is affected:</strong> Classpath containers that depended on JDT to resolve referenced libraries via JAR's MANIFEST.MF.</p>
		80	<p><strong>Description:</strong>
		81	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
		82	of a JAR's MANIFEST.MF were automatically added. In 3.6, referenced JARs are not automatically added any more. However, a classpath container
		83	implementor can use <code>JavaCore#getReferencedClasspathEntries()</code> to resolve the referenced JARs and return them in the implementation of
		84	<code>IClasspathContainer#getClasspathEntries()</code>.</p>
		85	<p>Please refer to the documentation of these APIs:<br>
		86	<ul>
		87	<li><code>IClasspathContainer</code></li>
		88	<li><code>JavaCore#getReferencedClasspathEntries()</code></li>
		89	</ul>
		90	<p><strong>Action required:</strong>
		91	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>
		92	list on start-up.</p>
		93
		94	<!-- ############################################## -->
77		95
78	</body>	96	</body>
79	</html>	97	</html>