Community
Participate
Working Groups
Projects in the real world don't always come in nice "sorted levels". Often, what's in project A and what's in project B depends on code ownership issues or other weird things. I presently own projects A and B, and there is another project P owned by other people. B depends on A; so far, so good. As far as P is concerned, the situation unfortunately is a mess: P depends on B, but I also need P to compile B. So I'm locked in a build cycle. Just to mention one more thing, I do want to autobuild B whenever I change A. What I end up doing: I have an ant script that builds a jar from A and B. I build that jar occasionally (my outer interface doesn't change all that often). I have P depend on that jar. When I fire up the main program, which is in P, I need to do tricks with the CLASSPATH at run time, so that I actually get the current version of A and B, as opposed to the stuff from the jar. It's a workable approach in my situation. But I feel that I'm playing games I shouldn't have to play, and that eclipse's support of build cycles among projects leaves to be desired. My suggestion: What would really help me is a new kind of "weak" project dependency that does not fire autobuild and is not taken into account in cycle detection. So I would have P weakly depend on A and B. Weak dependency should be easy for you to do. Here are the details: P will not autobuild when A or B change. When I rebuild P manually, or when P is autorebuild because of another project dependency, this will not cause A or B to be rebuild prior to P's build. P's build will grab out of A and B whatever happens to be there at the time of the P's build. Of course, in my case, B depends on P, so B will be autorebuild afterwards, but that's a different story. Likewise, whenever I run a program out of P, it will find in its CLASSPATH whatever happens to be in A or B at that moment (unless I configure otherwise).
Your claim is fully legite. The Eclipse current build infrastructure doesn't support cycles, but this is going to change (see 2.1 plans). The responsibility lies in Platform/Core which owns the build manager, and provide a couple adjustments for this. The weak dependency approach goes in the same direction as a change we implemented in last integration build (2.1 branch). In the Java>Compiler>Other preferences, you can decide the severity of each kind of classpath problem. Cycles can be downgraded to "warning", which would let the build run smoothly. However, this still only build each project in the cycle once. Platform should still allow to further build projects in a cycle incrementally until no more change is performed (with some limit in the number of iterations, in case of misbehaving builder implementations). By doing this, only one build action (when autobuild is off) would be necessary to correctly build a cycle. Moving to Platform/Core for further comments. I think JDT/Core already does the right thing (with latest changes).
Forgot to mention that the JDT/Core cycle change is also going to be backported into a 2.0.2 update.
*** This bug has been marked as a duplicate of 10262 ***
