Community
Participate
Working Groups
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
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 ?
Yes, it is OK to close. I am able to use the exclusion filter option to solve our situation. Thanks
Ok, closing.