Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 204704

Summary: cannot reference source output folder as library
Product: [Eclipse Project] JDT Reporter: Steve Mandl <sjm34>
Component: CoreAssignee: JDT-Core-Inbox <jdt-core-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: jerome_lanneluc
Version: 3.2.2   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard: stalebug
Attachments:
Description Flags
.classpath containing the workaround described in my update this morning
none
.project file related to the attached .classpath file none

Description Steve Mandl CLA 2007-09-26 12:12:07 EDT
I set up a project with two source folders. Each source folder has a different external output folder, each for the classes of distinct web applications in an enterprise  application. Since I don't have the full source of the enterprise application, I want to reference the output folders as libraries in my project. I can reference the output folder as a library if it the default output folder, but if it is listed as an output folder for a source folder, the java build path dialog complains that the source folder cannot output to a library. 
   I think the restriction should be consistent if the output folder is the default, or if it is source specific. Further, I think the restriction should be removed.
Comment 1 Jerome Lanneluc CLA 2007-09-28 04:55:36 EDT
If I understand your setup correctly, the reason that you can reference the default output folder is that no source folder will put .class files in the default output folder since each source folder has its own output folder.

I would suggest to put the .class files of the enterprise application in a separate folder, and add this folder as a library. Would that work for you ?

If it doesn't work for you, can you please explain in more details your setup? Maybe attaching the .classpath file would help.
Comment 2 Steve Mandl CLA 2007-09-28 09:00:20 EDT
What I am trying to do is extend existing classes which are in the classes folders of the applications. I want compiled output to go to the corresponding classes folders, and I also want to reference these classes folders in the build path.

I found a workaround to the original problem, which is to create two external resources for each class folder. To explain in more detail, I will call the two applications 'businessobjects' and 'uiweb'. The source folders are businessobjects-src and uiweb-src. The output folders (external) are businessobjects-output and uiweb-output. The library folders, which are external AND POINT TO THE SAME LOCATION AS AS THE OUTPUT FOLDERS, are businessobjects-lib and uiweb-lib. Since the -output and -lib folders are different external resources, I can configure the project to do what I want.

My issue is that I have to create separate -lib and -output folders for the same location. If I try to use a -lib as both a library and for source specific output, I get the message telling me that it is not allowed. However this restriction would not apply if the -lib folder was the default output folder for the project. I am proposing that the restriction rules become consistent whether the output is default or source specific. Also, since there is a need for using output folders that are libraries, this should be allowed, perhaps as a configurable option in the Java>Compiler>Building preference page. 

I understand this could wreak havoc if I had scrub output folders enabled, or if I inadvertently replaced existing classes. I think it would be more intuitive if I got a warning message instead of an error preventing me from doing it.

I will attach the .classpath with the workaround I described. Thanks for your help.
Comment 3 Steve Mandl CLA 2007-09-28 09:04:02 EDT
Created attachment 79382 [details]
.classpath containing the workaround described in my update this morning
Comment 4 Steve Mandl CLA 2007-09-28 09:05:06 EDT
Created attachment 79383 [details]
.project file related to the attached .classpath file
Comment 5 Eclipse Genie CLA 2019-01-09 08:50:30 EST
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.