### 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 @@ *
  • project entries (CPE_PROJECT)
    • * * In particular, a classpath container can neither reference further classpath containers or classpath variables. + *

    + * 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()}. *

    * 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 ClasspathContainerInitializer @@ -63,7 +67,10 @@ * * A classpath container can neither reference further classpath containers * or classpath variables. - *

    + *

    + * 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. *

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

  • {@link JavaCore#newProjectEntry(IPath, boolean)} and variants
    • *
  • {@link JavaCore#create(org.eclipse.core.resources.IWorkspaceRoot)}
    • *
  • {@link JavaCore#create(org.eclipse.core.resources.IProject)}
    • + *
  • {@link JavaCore#getReferencedClasspathEntries(IClasspathEntry, IJavaProject)} with null as project
    • *
  • {@link IJavaModel#getJavaProjects()}
    • *
  • {@link IJavaProject#getRawClasspath()}
    • *
  • {@link IJavaProject#readRawClasspath()}
    • #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 @@
  • SDK ships 2 org.junit plug-ins (versions 3.8.2 and 4.8.1)
  • Source incompatibility for subclasses of AbstractTemplatesPage
  • @SuppressWarnings("unchecked") does not ignore raw types warnings anymore
    • +
  • Classpath containers have the choice to resolve the referenced libraries themselves
    • @@ -74,6 +75,23 @@ private List l; +

    4. Classpath containers have the choice to resolve the referenced libraries themselves

    +

    What is affected: Classpath containers that depended on JDT to resolve referenced libraries via JAR's MANIFEST.MF.

    +

    Description: +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 JavaCore#getReferencedClasspathEntries() to resolve the referenced JARs and return them in the implementation of +IClasspathContainer#getClasspathEntries().

    +

    Please refer to the documentation of these APIs:
    +

    +

    Action required: +If the classpath container implementation cannot be changed to accommodate this, the 3.5 behavior can be retained by adding a system property (-DresolveReferencedLibrariesForContainers=true) to the -vmargs +list on start-up.

    + + #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 "back in time" to an earlier release, you will need that backup.

    - - +

    Users who use User Libraries or classpath containers that contain JARs referencing other libraries via Class-Path in the MANIFEST.MF

    +

    +If you want the referenced JAR files to be included in the classpath, you can do one of the following:
    +

    +

    6. Interoperability with Previous Releases

    6.1 Interoperability of Release 3.5 with previous releases