Community
Participate
Working Groups
Create a project called export_jre_src, with JRE_LIB on the classpath. Add a source folder (do not use the project as src) and export the JRE_LIB library. Create another project export_jre_full, with the project as source folder (as is the default) and also exporting the JRE_LIB library. Then make a project dependant which has no jcl, and depends on the export_jre_full project. Then create a class in this project. This will work as expected; it picks up the class library from the export_jre_full project. Now change the dependency from export_jre_full to export jre_src. Building will fail, complaining that it can't find the class java.lang.object on the classpath. This seems to be caused by the fact that now only the source folder of export_jre_src is on the classpath. This seems to be inconsistent behaviour.
Tried to reproduce in R2.0 but could not... both worked fine. Frank, which version are you using? Can you please paste in the .classpath files of the 3 projects involved... before and after the change.
Would it be occurring on Linux only ?
Works fine on Linux too... Frank, can you reproduce from scratch? Please paste in the .classpath files of the 3 projects involved... before and after the change.
Closing until we get repeatable steps.
Sorry about the late reply, but i just found out it only bugs out in case you use container variables. Simpler recipe is to create Project exporting, with JRE_LIB container exported on classpath, with a source and bin folder. .classpath file will be: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry exported="true" kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="output" path="bin"/> </classpath> <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="src" path="/Exporting"/> <classpathentry kind="output" path="bin"/> </classpath> Now try to create a class deriving from java.lang.object.... Then create a Project importing, with only the exporting project on the classpath. .classpath will be then
updated priority. Could be a showstopper ....
Reproduced... the exported container is not present in the classpath from the method JavaProject.getResolvedClasspath(boolean, boolean). Frank/Michael, how many container variables do you have? How reasonable (in the short term) is it for each project to include them instead of picking them up as an exported item from a prereq project?
We use lots of containers. Every WSDD project created uses them.
What's the drop dead date?
We freeze on Friday Aug 9th 2002. Any dates after this imply adding code in the middle of test passes, the GM date is Sept 10.
I seriously doubt we will have anything by this Friday... Philippe is away until Monday the 12th of August. Is there some reason that each project cannot add the containers themselves (which works fine) instead of picking them up as exported items?
Phillipe: The 'bug' is in the method JavaProject.getResolvedClasspath (IClasspathEntry[], boolean, boolean) The classpath entries are retrieved for the container but are not copied so the isExported flag can be set. Potential fix below: ------------------------------------------------------------------------------ switch (rawEntry.getEntryKind()){ case IClasspathEntry.CPE_VARIABLE : ... break; case IClasspathEntry.CPE_CONTAINER : IClasspathContainer container = JavaCore.getClasspathContainer (rawEntry.getPath(), this); if (container == null){...} IClasspathEntry[] containerEntries = container.getClasspathEntries(); if (containerEntries == null) break; for (int j = 0, containerLength = containerEntries.length; j < containerLength; j++){ IClasspathEntry containerRawEntry = containerEntries[j]; if (generateMarkerOnError) {...} if (rawEntry.isExported()) { containerRawEntry = new ClasspathEntry( containerRawEntry.getContentKind(), containerRawEntry.getEntryKind(), containerRawEntry.getPath(), containerRawEntry.getSourceAttachmentPath(), containerRawEntry.getSourceAttachmentRootPath(), true); } resolvedEntries.add(containerRawEntry); } break; default : resolvedEntries.add(rawEntry); }
For some history on this subject, Erich Gamma says that this may have been intentional, the idea of not exporting containers (or perhaps just the JRE ones?).
Well if that is the case then the UI should not let you tag a container as exported.
I don't see any reason why we would not export them, like other variable entries. I rather think this is a bug. Will look into it.
Would issuing it for 2.0.1 make it bearable for WSDD ? Will also try to post a patch in the meantime.
Kent's fix proposal would work, but require us to duplicate all exported classpath container entries upon resolution (which is quite often). The trick is that the involved container resolver is in charge of tagging the container entries as exported or not. However, it does not get enough information in order to do so (only gets the container path, not the container entry). So it is necessary for the classpath resolution mechanism to turn container nested entries into exported ones if necessary. Adopting suggested fix. Note: for classpath variables, the export flag is automatically associated during the resolution stage.
Fixed
Just a follow-up on: >Erich Gamma says that this may have been intentional, the idea of not >exporting containers (or perhaps just the JRE ones?). my concern was related to the run-time class path computation in the case of exporting multiple containers containing a JRE (->boot class path order), but the case seems to be handled properly now.
Verified
Verified.