This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Set compiler for sources to be ant indirect. When you compiler from a specific source file, compile is fine. If you pick a folder in the source file tree, and select build-all, the org.openide.compiler.DependencyExcption is thrown because ant gets stuck in a loop using the wrong build information. Mon Oct 29 11:06:57 EST 2001: org.openide.compiler.DependencyException: 3 compilers formed a cycle org.openide.compiler.DependencyException: 3 compilers formed a cycle at org.openide.compiler.Graph.getLevels(Graph.java:94) at org.openide.compiler.CompilerJob.computationLevels (CompilerJob.java:164) at org.openide.compiler.CompilationEngine.createComputationLevels (CompilationEngine.java:48) at org.netbeans.core.compiler.CompilationEngineImpl.createLevels (CompilationEngineImpl.java:123) at org.netbeans.core.compiler.CompilationEngineImpl$CompilerThread.run (CompilationEngineImpl.java:187) Compiler cycle: AntCompiler[project=build [EJB] [Up-to-date],target=all] [class=org.apache.tools.ant.module.run.AntCompiler,id=7937,hash=7658805] Includes: AntCompiler[project=build [EJB] [Up-to- date],target=all] [class=org.apache.tools.ant.module.run.AntCompiler,id=7937,hash=7658805] Depends on: AntCompiler[project=build [EJB] [Up-to- date],target=clean] [class=org.apache.tools.ant.module.run.AntCompiler,id=5241695,hash=97522397] AntCompiler[project=build [EJB] [Up-to-date],target=clean] [class=org.apache.tools.ant.module.run.AntCompiler,id=629,hash=97522397] Includes: AntCompiler[project=build [EJB] [Up-to- date],target=clean] [class=org.apache.tools.ant.module.run.AntCompiler,id=629,hash=97522397] Depends on: AntCompiler[project=build [EJB] [Up-to-date],target=all] [class=org.apache.tools.ant.module.run.AntCompiler,id=7937,hash=7658805] Includes: AntCompiler[project=build [EJB] [Up-to- date],target=all] [class=org.apache.tools.ant.module.run.AntCompiler,id=7937,hash=7658805] Depends on: [catch] AntCompiler[project=build [EJB] [Up-to- date],target=clean] [class=org.apache.tools.ant.module.run.AntCompiler,id=5241695,hash=97522397]
Created attachment 3190 [details] IDE.LOG
Svata, I think this is a duplicate of a bug filed long ago for the Ant module, please find it and mark duplicate as need be. I thought it was closed however.
Jesse, I don't think so -- at least the attached log says Oct 22th, so it is fairly recent.
Kenneth, could you, please, attach some simple project (zipped) so I have some test data ? Thanks.
Well clearly the problem was not fixed, but see the above two for more info (one of them you patched yourself, it seems). If you figure out what is going on, a unit test would be very helpful here.
Created attachment 3285 [details] Test Case That Exhibits Failure
When creating the test case, I noticed that the deletion of some files cause the problem to vanish ... If I delete the ~ file, the problem does not reproduce. If I delete the .rmi file, the problem does not reproduce. This may be caused by some file scan pattern match that is confusing the values passed into the ant compile. Note - this project does NOT compile without errors - it is trimmed down with many source files missing, so once you get past the exception, the compile will produce quite a few errors.
Thanks for the testcase; I'll try to nail it down tomorrow morning. Jesse - thanks for the testcase suggestion, could you please file a task for me on that ?
This time the openide seems innocent. Trimmed down to two objects (one java, one RMI), it looks like this: OpenIDE constructs a CompilerJob (j1) for the whole compilation task. It asks both A.java and RMI.java to add themselves to the job. A.java adds two compilers, Ant[all], which depends on Ant[clean]. RMI.java creates a supplemental CompilerJob (j2), which also contains Ant[all] depends on Ant[clean] and makes job j1 depend on job j2. Both Ant[all] compilers are equivalent (they return true from equals() on each other); the same do the Ant[clean] compilers. I believe that it is correct, because the Ant[clean] does clean for both java,rmi at once, so it is indivisible operation. The same applies to ant[all]. A dependency from X to Y means X cannot start before Y terminates. Specifically, if Y is a job (container essentially), X cannot start until all items of Y terminate. Since both Ant[all] (resp. Ant[clean]) are merged together, the situation is as follows: Ant[all]{j1} -> Ant[clean]{j1} -> Ant[all]{j2} == Ant[all]{j1} -> Ant[clean]{j2} == Ant[clean]{j1} So that means that Ant[all]{j1} depends on Ant[clean]{j1}, which in turn depends on Ant[all]{j1} -- the cycle is formed. My suggestion is that RMI module does not declare dependency from J1 to J2, but instead of that make its RMI Stub Compiler, inserted into J1, dependent on J2. The graph won't then contain cycles and will be processed correctly. I've decided to bump the priority, this bug has bad effects on Ant/RMI integration in the IDE.
I'm not sure I agree with the P2 designation. Using Ant Indirect Compilation and as well as Ant Compilation are rather deprecated by now (and will probably be deleted in a future release, not 3.3). There is not much point in a user setting things up like this; he could just write RMI-processing targets into the Ant script, and not use Ant Indirect Compilation at all, in which case there would be no problem. I would probably suggest P3 plus a FAQ item "when using Ant with RMI, don't use indirect ant compilation...". Of course if it is easy to fix, it should be.
Target milestone -> 3.3.1.
Fixed by inserting the java Compilers(J_C) into special CompilerJob (CJ1) and RMI compilers (RMI_C) into default CompilerJob (CJ2) and setting dependency: RMI_C ---depends----> CJ1. By this arangement of compilers the cycle is broken.
verified
Resolved for 3.4.x or earlier, no new info since then -> closing.