Community
Participate
Working Groups
This relates to bug 305037. In 3.5, when a JAR file that is part of a container refers to another JAR through the MANIFEST.MF, those dependencies were resolved and included as part of the project's classpath. However, this is no longer the case from 3.6 as discussed in bug 305037. Those containers that need this kind of dependency to be resolved must do it themselves, probably by using IClasspathContainer#getClasspathEntries() or some other ways.
> probably by using IClasspathContainer#getClasspathEntries() In fact, the container *implements* IClasspathContainer#getClasspathEntries(). To find referenced entries, it can use JavaCore#getReferencedClasspathEntries(..). I.e. the Javadoc of IClasspathContainer#getClasspathEntries() should contain: * <li>{@link JavaCore#getReferencedClasspathEntries(IClasspathEntry, IJavaProject)} with <code>null</code> as project</li>
Created attachment 169638 [details] Proposed patch Patch with the migration guide entry and the Javadoc change suggested by Markus. Markus/Dani, please advise what our course of action for bug 313965 would be. We will need this documentation changes depending on that.
Created attachment 169852 [details] Patch 2 (Javadoc only) (In reply to comment #2) > Created an attachment (id=169638) [details] [diff] > Proposed patch The patch misses the link proposed in comment 1. Here's a version with a few more improvements. Jay, when you update the Migration Guide in the light of bug 313965, please make it more clear that the 3.5 behavior is considered a bug, e.g.: "In 3.5, a classpath container 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 added any more, but a classpath container implementor can resolve them via JavaCore#getReferencedClasspathEntries(..) and return them in its implementation of IClasspathContainer#getClasspathEntries()."
Created attachment 170020 [details] Updated patch Posting the latest patch for review. Updated the migration guide (incompatibilities section), Javadoc (no change from the prevous patch) and readme file. Please let me know if any other section in the readme file has to be updated.
Looks good to me.
Just realized that the JVM parameter could be improved as the current one seems to be very ambiguous. Markus/Olivier, Any suggestions that is short yet meaningful?
-DincludeReferencedLibrariesInContainers If this is documented, it should be enough.
Created attachment 170062 [details] Patch with better property name System attribute name slightly modified than the one suggested. Otherwise, nothing else has changed other than a couple of minor fixes.
I think you meant: -DresolveReferencedLibrariesForContainers=true in the readme_eclipse.html file and the incompatibilities.html file.
Created attachment 170087 [details] Proposed fix New patch with =true instead of =false.
(In reply to comment #10) > Created an attachment (id=170087) [details] > Proposed fix > > New patch with =true instead of =false. Patch looks good. Just an editorial comment: "can not" should be "cannot". See : http://www.askoxford.com/asktheexperts/faq/aboutspelling/cannot
Agree with comment 11. Jay, please commit to HEAD once we commit bug 313965. I will then commit the readme part since you don't have commit rights for that.
Created attachment 170163 [details] Fix 5 +1 for RC3. This patch contains the change from comment 11 plus: incompatibilities.html: - removed bad </p> - changed <ol> to <ul> (it's not a sequence, so bullets are better) - "Please refer to the documentation under the following sections for further reference:" -> "Please refer to the documentation of these APIs:" - added a comma after "However" (avoids ambiguous beginning that forces readers to backtrack) readme_eclipse.html: - added "via Class-Path" (I guess many readers don't know about this mechanism, so we should spell it out) - replaced "(or)" with ", or" - removed "if possible"
Created attachment 170164 [details] Fix 6 Previous patch was incomplete.
Created attachment 170165 [details] Fix 7
Release all changes except readme_eclipse.html in HEAD for 3.6 RC3. Dani, Could you please release readme_eclipse.html? I will move the bug to "FIXED" after that.
> Dani, > Could you please release readme_eclipse.html? Done.
Thanks, Dani. Moving to Resolved.
FYI: I filed bug 314682 for a problem in Eclipse's CVS that caused the incomplete patches I attached.
Thought that this deserved wider circulation... http://lt-rider.blogspot.com/2010/05/jdt-manifest-classpath-classpath.html This post should be picked up by Planet Eclipse soon. Let me know if I've misrepresented anything and I will correct. I don't have any issue with this content being re-used in official release notes if that is deemed beneficial. Let me know if you want to do that and I will attach the text to this bug to make it an "official contribution" so that IP deities remain pleased.
(In reply to comment #20) > http://lt-rider.blogspot.com/2010/05/jdt-manifest-classpath-classpath.html Interesting blog. You might also want to mention that Galileo behavior was wrong as a container should control exactly what is inside the container. So Helios fixed this issue.
> Interesting blog. You might also want to mention that Galileo behavior was > wrong as a container should control exactly what is inside the container. So > Helios fixed this issue. Sure. Will mention this. I can certainly see how it is good to give container implementations more control, but it would have been nice had this been done in a way that implementations can opt-in for more flexibility rather than changing behavior that already shipped that users and extends can be depending on. There is also not denying the fact that you've taken away a feature from user library facility. I imagine that you might restore this in a future release in a manner that gives user library container more control, but that's not going happen in time for Helios, so at least in this way Helios is less capable than Galileo. Oh well...
Verified for 3.6RC3 using build I20100527-1700 and readme file content from HEAD stream...
