View | Details | Raw Unified | Return to bug 313890 | Differences between
and this patch

Collapse All | Expand All

(-)model/org/eclipse/jdt/core/IClasspathContainer.java (-3 / +8 lines)
Lines 1-5 Link Here
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
 * It is possible that the library entries (that are JAR files) can further reference other libraries through the
32
 * Class-Path section of the MANIFEST.MF file. If the container wants such referenced entries to be 
33
 * part of the classpath, they must be provided via {@link IClasspathContainer#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 61-68 Link Here
61
	 * <li> library entries (<code>CPE_LIBRARY</code>) </li>
65
	 * <li> library entries (<code>CPE_LIBRARY</code>) </li>
62
	 * <li> project entries (<code>CPE_PROJECT</code>) </li>
66
	 * <li> project entries (<code>CPE_PROJECT</code>) </li>
63
	 * </ul>
67
	 * </ul>
64
	 * A classpath container can neither reference further classpath containers
68
	 * The set may include the library entries that are referenced via the MANIFEST.MF file.
65
	 * or classpath variables.
69
	 * However, a classpath container can neither reference further classpath containers
70
	 * or classpath variables. 
66
	 * </p>
71
	 * </p>
67
	 * <p>
72
	 * <p>
68
	 * This method is called by the Java model when it needs to resolve this
73
	 * This method is called by the Java model when it needs to resolve this
(-)porting/3.6/incompatibilities.html (+16 lines)
Lines 21-26 Link Here
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">Class-Path references via MANIFEST.MF are not resolved automatically for containers</a></li>
24
</ol>
25
</ol>
25
26
26
<hr>
27
<hr>
Lines 75-79 Link Here
75
</pre>
76
</pre>
76
<!-- ############################################## -->
77
<!-- ############################################## -->
77
78
79
<h2>4. <a name="ReferencedLibraries">Class-Path references via MANIFEST.MF are not resolved automatically for containers</a></h2>
80
81
<p><strong>What is affected:</strong> Classpath containers (implementors of IClasspathContainer) that depend on JDT to resolve referenced libraries via MANIFEST.MF.</p>
82
83
<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>
84
85
<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> 
86
87
<p>Please refer to the Javadoc of the following sections for further reference:<br>
88
<ol><code>
89
<li>IClasspathContainer<br></li>
90
<li>JavaCore#getReferencedClasspathEntries()</li>
91
</code></ol>
92
</p>
93
<!-- ############################################## -->
78
</body>
94
</body>
79
</html>
95
</html>

Return to bug 313890