Bug 40984 - IJavaProject.setRawClasspath, IJavaProject.setOutputLocation - undesirable effect of copying of all resources from old output location to new output location IJavaProject.setOutputLocation
Summary: IJavaProject.setRawClasspath, IJavaProject.setOutputLocation - undesirable ef...
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows 2000
: P3 normal with 1 vote (vote)
Target Milestone: 3.0 M4   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-30 19:18 EDT by Hetty Dougherty CLA
Modified: 2003-09-29 04:36 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hetty Dougherty CLA 2003-07-30 19:18:01 EDT
Tested with 07/26 WSAD build from Raleigh.

IJavaProject.setRawClasspath and IJavaProject.setOutputLocation now copy all 
resources from old output location to new output location ?
It seems that someone else also is not sure if this is the right thing to do : 
Here is the comments in BatchImageBuilder.copyExtraResourcesBack.

protected void copyExtraResourcesBack(ClasspathMultiDirectory sourceLocation, 
final boolean deletedAll) throws CoreException {
// When, if ever, does a builder need to copy resources files (not .java 
or .class) into the output folder?
// If we wipe the output folder at the beginning of the build then all 'extra' 
resources must be copied to the output folder. 
    
This has a very undesirable effect on the data definition view within the Data 
perspective.  The following example illustrates the problem.
    
1. Go to Java perspective. 
2. Create a Java project (e.g. myjavaproj) and take all the defaults. The 
default output folder is set to the project folder.
3. Go to Data perspective.
4. From Data Definition view, create DB, Schema, a table, a default SQL SP in 
the project from step 1.
5. Go back to the Java perspective
6. Bring up the properties dialog of the Java project.
7. Change the Default output  folder to myjavaproj to myjavaproj/myoutputdir . 
myoutputdir does not exist yet.
    Press OK.
   All resources including the EMF persistence files for the database objects 
such as .dbxmi, schxmi, .tblxmi, .spxmi, are
   copied from the old output location (myjavaproj) to the new output location 
(myjavaproj/outputdir ).
     
8. Go back to the Data Definition. Now the data elements are replicated in the 
myjavaproj/myoutputdir because 
    the EMF persistence files (.dbxmi, .schxmi, etc) were copied into the new 
output location (myjavaproj/myoutputdir).     
    These files have special significance to the data view and should not have 
been copied to the new output location.   

Here is the call stack leading to copying of the output folder that you may 
find useful

org.eclipse.core.launcher.Main at localhost:8170 (may be out of synch)
System Thread [Finalizer] (Running) (may be out of synch)
System Thread [Reference Handler] (Running) (may be out of synch)
System Thread [Signal dispatcher] (Running) (may be out of synch)
Thread [main] (Suspended)
	BatchImageBuilder$3.visit(IResourceProxy) line: 180
	Resource$1.visitElement(ElementTree, IPathRequestor, Object) line: 50
	ElementTreeIterator.doIteration(DataTreeNode, IElementContentVisitor) 
line: 76
	ElementTreeIterator.doIteration(DataTreeNode, IElementContentVisitor) 
line: 80
	ElementTreeIterator.iterate(IElementContentVisitor) line: 119
	Project(Resource).accept(IResourceProxyVisitor, int) line: 60
	BatchImageBuilder.copyExtraResourcesBack(ClasspathMultiDirectory, 
boolean) line: 170
	BatchImageBuilder.cleanOutputFolders() line: 113
	BatchImageBuilder.build() line: 37
	JavaBuilder.buildAll() line: 194
	JavaBuilder.build(int, Map, IProgressMonitor) line: 122
	BuildManager$2.run() line: 427
	InternalPlatform.run(ISafeRunnable) line: 1006
	Platform.run(ISafeRunnable) line: 413
	BuildManager.basicBuild(int, IncrementalProjectBuilder, Map, 
MultiStatus, IProgressMonitor) line: 125
	BuildManager.basicBuild(IProject, int, String, Map, MultiStatus, 
IProgressMonitor) line: 181
	BuildManager.basicBuild(IProject, int, ICommand[], MultiStatus, 
IProgressMonitor) line: 191
	BuildManager$1.run() line: 151
	InternalPlatform.run(ISafeRunnable) line: 1006
	Platform.run(ISafeRunnable) line: 413
	BuildManager.basicBuild(IProject, int, MultiStatus, IProgressMonitor) 
line: 165
	BuildManager.basicBuildLoop(IProject[], IProject[], int, MultiStatus, 
IProgressMonitor) line: 243
	BuildManager.build(int, IProgressMonitor) line: 212
	Workspace.endOperation(boolean, IProgressMonitor) line: 884
	Workspace.run(IWorkspaceRunnable, IProgressMonitor) line: 1600
	JavaElement.runOperation(JavaModelOperation, IProgressMonitor) line: 543
	JavaProject.setRawClasspath(IClasspathEntry[], IPath, IProgressMonitor, 
boolean, IClasspathEntry[], boolean, boolean) line: 2159
	JavaProject.setRawClasspath(IClasspathEntry[], IPath, IProgressMonitor) 
line: 2123
Comment 1 Philipe Mulet CLA 2003-08-06 05:32:34 EDT
The support for copying resource to output folder is working as intended, so as 
to avoid runtime resource lookup to require addition of source folders on 
runtime classpath. If you don't want this behavior, it can be disable via 
options (exclusion filters or exclude list for resource copy behavior).

Moreover, if you don't want resource to be copied to output, then don't place 
any inside source folders, but rather put them in library folders which are 
left untouched and appended to the runtime path.

Downgrading, since working as intended, configuration problem.

Ok to close ?
Comment 2 Hetty Dougherty CLA 2003-09-26 17:20:47 EDT
Yes, it is OK to close.
I am able to use the exclusion filter option to solve our situation.
Thanks
Comment 3 Philipe Mulet CLA 2003-09-29 04:36:21 EDT
Ok, closing.