Community
Participate
Working Groups
Build ID: 3.5 We register a builder to statically instrument code using probekit technology (in TPTP). Everytime there is a change in the java source, the JDT builder kicks off the java compiler and then our builder gets called to instrument the code (modify the class file). This works perfectly in all scenario's except in the one where the user defines an Class Folder or External Class Folder on the build path. The problem in that scenario is that there is we are spun into an infinite build loop. Seems as though after our builder runs and modifies the class files, this change kicks off a full build in eclipse and the loop starts again. To reproduce 1) Create 2 java projects Project1 - Has our tooling enabled and our custom builder is registered. Note that you won't need to use our builder/tooling to reproduce - any custom builder that modifies the class files will be sufficient to reproduce the problem. - In the project properties, add the Project2 as a class folder (click 'Add Class Folder...' on the Java Build Path -> Libraries tab) Project2 - Normal java project. Nothing special on the build path. 2) Click OK and open the 'Progress' view. Note that there is a builder job almost constantly building. This is the problem. It might be easier to detect when the builders are called by turning on the debug mode in the org.eclipse.jdt.internal.core.builder.JavaBuilder class and checking the console output (or putting a breakpoint in the build() method in that class to see how many times it's called). I debugged the problem into the findDeltas() method in org.eclipse.jdt.internal.core.builder.JavaBuilder. After our builder instruments the class file, it seems as though the JavaBuilder will detect the changes and determine if a build is required. In this particular case, it will detect that Project1 has changed and try to find a delta on Project2 - when it can't find one it returns null: delta = getDelta(p); if (delta != null) { // removed } else { if (DEBUG) System.out.println("Missing delta for: " + p.getName()); //$NON-NLS-1$ this.notifier.subTask(""); //$NON-NLS-1$ return null; <------- this is the problem? } This will result in the JavaBuilder initiating a FULL BUILD (which spins us into the problem). Note that if you add a project on the build path (Properties -> Java Build Path -> Projects -> Add Project2) this problem will not occur. Seems as though the external class folders are treated differently by the builder.
Increasing severity because of problems this is causing in consuming products
So just to be clear, you're adding Project2 as a ClassFolder & not a dependent project ? And neither Project1 or Project2 have any source or bin folders ?
(In reply to comment #2) > So just to be clear, you're adding Project2 as a ClassFolder & not a dependent > project ? > Yes, correct. Adding Project2 as a class folder causes the problem. The problem does not occur when it's listed as a dependent project. > And neither Project1 or Project2 have any source or bin folders ? > I guess I should have been more clear here. When I say that Project1 and Project2 are regular java projects, I mean that both projects have at least one java class file. A simple 'HelloWorld' class will be sufficient (only main() with System.out.println). Note that this problem occurs even if Project1 doesn't require any classes from Project2. You could create the HelloWorld class in Project1 and keep Project2 completely empty (no class files) - the problem can be reproduced simply by adding the Project2 class folder.
"the problem can be reproduced simply by adding the Project2 class folder." But you're not adding the bin folder of Project2 as a .class folder, you're adding the project itself... and not as a dependent project, as intended. Why? (I'm not saying we shouldn't detect this setup) The obvious easy change is to add the dependent project AS a dependent project.
(In reply to comment #4) > "the problem can be reproduced simply by adding the Project2 class folder." > > But you're not adding the bin folder of Project2 as a .class folder, you're > adding the project itself... and not as a dependent project, as intended. > > Why? (I'm not saying we shouldn't detect this setup) > > > The obvious easy change is to add the dependent project AS a dependent project. > For no reason other than it came up during testing. I do agree with you that the test case I outlined is not the most intuitive way to create a project dependency, but I do think it's a valid configuration. As such, we need to be able to handle this scenario. Like I mentioned before, creating a project dependency (in the Java Build Path -> Projects tab) does not cause the problem. We're just trying to cover ourselves in situations where the user adds the class folder.
Created attachment 129882 [details] Proposed patch Paul, please try this 1 line change to see if it fixes your case. The change detects when the class folder is just a project & treats it as an output folder. thx
Patch looks good. Thanks Kent
Created attachment 129892 [details] Proposed patch and testcase
Fix and test released for 3.5M7
Verified for 3.5M7 (Verified by reporter)
