Community
Participate
Working Groups
Created attachment 277382 [details] Sample projects MainProjectWithTests, TestUtils on which JDT reports a cyclic dependency I have two projects: MainProjectWithTests (MP) and TestUtils (TU) The "main" code of MainProjectWithTests (MP-M) has no dependencies. The test code of MainProjectWithTests (MP-T) depends on (MP-M) the main code of the TestUtils. The main code of the TestUtils (TU-M) depends on (MP-M). MP-M (no dependencies). TU-M --> MP-M MP-T --> MP-M, TU-M So with the separation into source folders and source folders containing test code and test code only dependencies, we have an acyclic graph. JDT reports a cyclic dependency between MP and TU. This is correct when the dependencies take the project dependencies only as a whole into account. With the new feature of source folder containing test code and dependencies without test code, this could be more fine grain. I attached two sample projects with this project and dependency structure. (But without containing code.)
I am not sure if the builder infrastructure in Platform can possibly support this. AFAIK, builds are triggered at project granularity, so if MP-M is modified, also TU has to be compiled for TU-M. After a build of TU, also MP has to be compiled (for the MP-T --> TU-M dependency), which would never terminate. Till can certainly give more precise answers.
(In reply to Stephan Herrmann from comment #1) > I am not sure if the builder infrastructure in Platform can possibly support > this. AFAIK, builds are triggered at project granularity, so if MP-M is > modified, also TU has to be compiled for TU-M. After a build of TU, also MP > has to be compiled (for the MP-T --> TU-M dependency), which would never > terminate. The severity of the message > A cycle was detected in the build path of project '...'. The cycle consists of projects {...} can be lowered from Error to Warning. Then, Eclipse just works - but with displaying a warning. (This is what we did to be able to work.)
I can only confirm what Stephan wrote. Build order computation is done on the project level. As you already found out, Eclipse actually can handle build cycles, in which case the involved projects are incrementally build multiple times. But personally, I'd rather avoid the situation you're describing and move MP-T to its own project ("MainProjectTests" ?). BTW: When implementing test source support, my first attempt was to create a hidden test "companion project" for each java project (using a hidden directory, linked resources and resource filters). This kind of worked and would have supported the use case of this bug, but it also leaked into the UI everywhere, so I gave up on this.
Thanks, Till. Do you see benefit in moving this to Platform to add new API that would allow sub-project-level build order computation? Otherwise, this sounds like WONTFIX, right?
I'd say WONTFIX
(In reply to Till Brychcy from comment #5) > I'd say WONTFIX done :) (sorry, Andreas, we can't fix this in JDT)
