Community
Participate
Working Groups
Eclipse used not to be able to build projects with circular dependencies. There was a bug 10262 which resulted from this deficiency. Bug 10262 was fixed recently. Eclipse will now iterating long enough until finally nothing changes any more. As a person concerned about build management, I do not think this is a clean way to fix the underlying problem. To look at it from a performance perspective: Under many common circumstances, a lot of build activity will be spend build stuff that will be thrown away in the next iteration. Both from an architectural as well as from a performance point of view, I propose that Eclipse should have the infrastructure neccessary to support one-shot build across projects. References: An 1997 essay, which has become rather famous in the make-community, "Recursive Make Considered Harmful", http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html While Eclipse does not use "make", and the part of the essay concerned with the speed of various makefile-construct is not relevant here, the basic issues are still the same. Indeed, the road that has now been taken by Eclipse is discussed in section "traditional solutions" (the implication being "non-solutions"), in 3.3.2. The other references is the discussion in bug 10262.
We run into this exact situation today. We have a large project comprised of ~7000 classes in ~150 projects, organized by function and application tier. Repeatedly trying to rebuild projects, although time-consuming, eventually works for us and resolves the dependency errors for all of our projects except 3. We have three projects such that project A depends on B, B depends on C, and C depends on A. These 3 projects cannot be built no matter what we do. Regardless of how many times we try to rebuild each project, the build is not able to complete far enough so that the other dependent classes can be built -- we basically get a "stalemate". In order to resolve this problem, we located one or two classes that we deduced would resolve the stalemate and had use "javac" from the command line to manually compile the classes. After these key classes were manually compiled, rebuilding the 3 projects in Eclipse was able to complete fine. Obviously, no matter how many times a builder would iterator over our projects, this "stalemate" scenerio will never be resolved; however, a "one-shot build across projects" would resolve this problem. Perhaps there could be "project sets" defined that would be treated as a single build unit...
Eclipse 3.0 will have a feature to allow the manual building of project working sets. Moving to JA for comment/closure.
Working set build doesn't address this particular feature request. Moving back to the open bucket.
Marking old enhancement requests that we don't intend to fix in the near future as RESOLVED LATER. This does not mean we will never do them, but it means we have no specific plans to address them.
[LATER->WONTFIX] The "LATER" bugzilla resolution is being removed so reopening to mark as WONTFIX.