Bug 21749 - Exported libraries and source folders
Summary: Exported libraries and source folders
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: 2.0.1   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-07-22 05:55 EDT by Frank Cornelissen CLA
Modified: 2002-08-19 11:20 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Cornelissen CLA 2002-07-22 05:55:41 EDT
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.
Comment 1 Kent Johnson CLA 2002-07-22 11:49:40 EDT
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.
Comment 2 Philipe Mulet CLA 2002-07-23 17:36:07 EDT
Would it be occurring on Linux only ? 
Comment 3 Kent Johnson CLA 2002-07-24 14:46:30 EDT
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.
Comment 4 Kent Johnson CLA 2002-08-01 12:43:33 EDT
Closing until we get repeatable steps.
Comment 5 Frank Cornelissen CLA 2002-08-02 09:01:27 EDT
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

Comment 6 Frank Cornelissen CLA 2002-08-06 10:30:24 EDT
updated priority. Could be a showstopper ....
Comment 7 Kent Johnson CLA 2002-08-06 14:18:53 EDT
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?
Comment 8 Michael Van Meekeren CLA 2002-08-06 14:52:15 EDT
We use lots of containers.  Every WSDD project created uses them.
Comment 9 Kent Johnson CLA 2002-08-06 14:57:10 EDT
What's the drop dead date?
Comment 10 Michael Van Meekeren CLA 2002-08-06 15:20:52 EDT
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.
Comment 11 Kent Johnson CLA 2002-08-06 15:40:18 EDT
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?
Comment 12 Kent Johnson CLA 2002-08-06 16:57:29 EDT
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);
}
Comment 13 Michael Van Meekeren CLA 2002-08-08 10:34:09 EDT
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?).  
Comment 14 Kent Johnson CLA 2002-08-08 11:15:35 EDT
Well if that is the case then the UI should not let you tag a container as 
exported.
Comment 15 Philipe Mulet CLA 2002-08-09 07:46:10 EDT
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.
Comment 16 Philipe Mulet CLA 2002-08-09 07:47:10 EDT
Would issuing it for 2.0.1 make it bearable for WSDD ? Will also try to post a 
patch in the meantime.
Comment 17 Philipe Mulet CLA 2002-08-09 08:55:54 EDT
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.
Comment 18 Philipe Mulet CLA 2002-08-09 09:04:25 EDT
Fixed
Comment 19 Erich Gamma CLA 2002-08-09 10:35:15 EDT
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.
Comment 20 Jerome Lanneluc CLA 2002-08-19 07:37:57 EDT
Verified
Comment 21 David Audel CLA 2002-08-19 11:20:23 EDT
Verified.