Community
Participate
Working Groups
Dear experts, my project contains sources I need for debugging, but which are not compileable due to missing classpath elements. These sources are tagged with exclusion filter ("*"). This works OK when performing a manual rebuild of the project. The sources are ignored. When the system performs a re-build automatically (e.g. because the sources have changed and I directly e.g. perform an external program call or enter the debugger), the exclusion filters are not applied and errors appear in the task list. They vanish only if I perform a manual re-build. Additional Info: Checkbox "Perform build automatically on resource modification" is not set in my case. Juergen Kremp
Juergen: The code for the builder is pretty much the same regardless of the type of build. We will need steps to reproduce this problem. Can you duplicate with a small project?
The effect can be reproduced with a very simple project. It consists of two source folders "CodeIn" and "CodeOut", of which the last one has exclusion filter "*" because it generates errors when compiling (in the demo, I use a missing import statement). This is the ".classpath" file: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="src" path="CodeIn"/> <classpathentry excluding="*" kind="src" path="CodeOut"/> <classpathentry kind="output" path="bin"/> </classpath> The sources are: Class "Test" in source folder "CodeIn": package test; public class Test { public static void main(String[] args) { System.out.println("Hello"); } } Class "AnyClass" in source folder "CodeOut": package testOut; public class AnyClass { public static void main(String[] args) { HashTable a; } } Now I perform a "Rebuild All" --> No errors are reported --> Exclusion filter works. When I perform "Build All" (CTRL-B), the effect depends on what file was changed before. If I change "Test" and then perform "Build All", no errors appear. When the other file "AnyClass" was changed, the error is reported. The effect in my productive environment is this: My project contains large amount of external code (needed for debuggging). This code changes every now and then because it is controlled by a source control system with regular updates. Whenever this happens and I perform a build of my project ("Build All" or Eclipse does it itself when I enter the debuggin), Eclipse tries to compile all these external classes, although there is the exclusion filter. My workaound is to perform once "Rebuild all", then the errors do not occur any more until the sources change next time (happens approx. once per day, so this is an acceptable workaround).
In your example, you need to specify the pattern as '**' to exclude all the files & subfolders of CodeOut. We have a consistency issue which we need to resolve & it may be the full build case which is changed... not the incremental build. The problem has to due with how a source folder is handled in this case. The full build starts by walking each source folder. The incremental build starts by walking the changed children of each source folder.
Hi Kent, when changing exclusion filter from "*" to "**", the java classes are not longer recognized in their package structure (they appear as in a file browser) and, more important, it is not longer possible to set break-points. This is the core feature why I have the sources in my project (debugging). So changing the system behavior as described above will mean a significant worsening of the usability. Juergen
Sorry I don't understand... you're setting an exclusion filter on one of your source folders so the builder will not compile the .java files in that source folder, correct? Well the exclusion filter applies to everything in JDT core. That means the packages & types will not be visible to the Java Model, and as a result the package explorer. You cannot set breakpoints in them since the builder never will recompile them... etc. Exclusion filters are meant to hide certain source files & packages from a project. The obvious way to handle your case was to never add CodeOut as a source folder in the first place, because that is what excluding everything means. Am I missing something?
Maybe I should make more clear what my "goal" is: I develop Java code, lets say for a servlet. So I have the required classpath elements in my project, e.g. "servlet.jar". The source folders of my project hold the servlet I develop (MyServlet.jar). After deploying the servlet into a J2EE application server, I can debug my servlet by setting a break-point into the source of the servlet, connecting to the server via remote debugging, and accessing the servlet via browser. So far no problem. My issue is that the application server itself is buggy and I must identify the bugs in it. To do so, I must be able to debug the server as a whole, so I must have the sources somehow in Eclipse and be able to set break-points, e.g. in the servlet container class. The server sources are available to me, but they are so large and require so many classpath elements to be compilable that I do not want Eclipse to even attempt to compile the scrap. The exclusion filters were seen to be a replacement for the privious (2.0) technology to create a "Server" project and enter it as dependent project in the serlvet project (which had the additional disadvantage that to compile my project in Eclipse, the server project must be open, too). So what I probably would need is not an "exclude completely" filter, but a kind of "exclude from compilation, but not from code analysis" filter.
As long as your server.jar was compiled with debug info, you should be able to attach the source & set breakpoints... at least I think you can. So I'm going to close this PR since exclusion filters were not designed for this purpose. Create a new PR in jdt.debug if you cannot debug the server.jar with the source attached (assuming it has the necessary debug info). Ok?
I'm afraid there is a misunderstanding. The problem is not "servlet.jar" that I have in my project to be able to write servlets. The problem are the 2000+ java classes that make up the application serveR, which cannot be compiled. But I must be able to set break-points in them to debug the serveR (not servleT). I cannot use "source attachment" technique for the server classes because I do not have the JAR's that make up the server in the Eclipse classpath (they are too many and would mess up my project). I also cannot include the sources simply into my project because then my project would permanently have errors. I now use a linked folder with exclusion filter "*" to have the serveR sources in my project and I can set break-points in the serveR code, and Eclipse does not try to build the 2000+ classes when doing "Rebuild All" (which is good). So I was VERY HAPPY with the new Eclipse 2.1 (especially because using linked folders I could have the large amount of serveR sources outside the project folder). Can you evaluate my problem under this aspect (remote debugging of a larger framework whose sources are present, but not compilable in the local environment). What is the intended way to proceed in such a case with Eclipse?
But the only way that this is 'working' is because of a bug in the way the Batch builder is skipping the 'excluded' source folder. IF we decide to change the batch builder to handle the excluded folder the same way as other parts of JDT then we would end up compiling every .java file contained in a package of the excluded source folder... just not the immediate .java files in the default package (ie. the folder's root directory). My guess is you should add a linked folder to the serveR classes as a library folder (ie. .class files only)... Darin: Can you help him out?
The 2.1/2.0 debugger does not support breakpoints in "external" source (i.e. source that is not on the buildpath). This is something we are working on for 3.0. The debugger supports source lookup in external source - but you have to "step into" it from "internal source", or suspend there due to an exception etc. It is not yet possible to set line breakpoints in the external source.
The answer from Darin clarifies that my current usage of exclusion filters lets me "simulate" a feature that is only available in version 3.0. Therefore, I now have the confidence that I am not missing the "right method" to accomplish my goal, but that it is officially not supported yet (but about to come). Regarding the reported issue, please decide for the best of the product. For my goal, a "fix" would be a drawback, but I have full understanding for a removal of the "inconsistency" that Kent mentioned.
Re-Posting and extension of my previous post, because the latter seemed to be corrupted somehow (strange fromatting and I did not get a configuration mail): The answer from Darin clarifies that my current usage of exclusion filters lets me "simulate" a feature that is only available in version 3.0. Therefore, I now have the confidence that I am not missing the "right method" to accomplish my goal, but that it is officially not supported yet (but about to come). Regarding the reported issue, please decide for the best of the product. For my goal, a "fix" would be a drawback, but I have full understanding for a removal of the "inconsistency" that Kent mentioned. Using the class-files of the server as external library (as suggested by Kent) is also not feasible in my case because the server is not on my desk and not in my reach, but somewhere in a computer center. I can attach to it via remote debugging only. The sources of the server (my objects of interest for bug location in the server in conjunction with my project files) are available to me via a source control system that can sync the sources to my hard disc (but not into my Eclipse project folder).
Darin: It is now possible to set line breakpoints in the external source?
Yes - you can set breakpoints in external source. The breakpoint will not currently appear in the editor (since the editor for external files does not have a ruler), but it will appear in the breakpoints view. You need to use the actions on the top level "Run" menu to toggle breakpoints in external source.
Can we close this bug now ?
Yes I think we can close it now.
