Community
Participate
Working Groups
I introduced a dependency cycle between some of my Java projects. I have about 100 projects in my workspace and now I have 58 warnings that a dependency cycle has been detected for project ... (substitute a different project for each warning). No additional information is given. This makes it a lot more work to figure out what the cycle is. The UI should report what the cycle is (for example by adding (ProjectA->ProjectB->ProjectC->ProjectA) to the text of the warning; I do understand that this is potentially a very long string).
Deferring post 3.1
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
Just ran into that as well: when we report a cycle on a project we should at least differentiate whether the project is part of the cycle or whether it only references a cycle: A -> B -> C -> B ==> The build path of project 'A' references projects that build a cycle A -> B -> C -> A ==> A cycle was detected in the build path of project 'A' The PDE editor can then be used to detect the cycle.
*** Bug 291274 has been marked as a duplicate of this bug. ***
The best we can do with the cycle detection is to display the list of projects involved in the cycle. Since a set is used to store project's paths in the cycle, the project's names would be displayed in a random order. Would this be sufficient ?
(In reply to comment #5) > The best we can do with the cycle detection is to display the list of projects > involved in the cycle. > Since a set is used to store project's paths in the cycle, the project's names > would be displayed in a random order. > Would this be sufficient ? How hard is it to replace the set with a list?
It is not hard. It is just less efficient.
(In reply to comment #7) > It is not hard. It is just less efficient. k. We could build the graph after the fact i.e. in the rare case we detect a cycle we build the full graph. That way only users with cycles pay.
Ayushman, please investigate. The only thing we should do at this time is to create a string representation of the cycle that we can put as part of the message for the problem reported for classpath cycle.
Would be good for RC1
If ready in time for M7, this should go in M7.
Created attachment 193981 [details] patch under test This changes the error message from "A cycle was detected in the build path of project P" to "A cycle was detected in the build path of project P. The cycle consists of projects {P, P1, P2}" Running tests to check what all tests need to be updated.
Created attachment 193987 [details] proposed fix v1.0 + regression tests The above fix with the tests updated to reflect the new error message.
Created attachment 194014 [details] proposed fix v1.1 + regression tests Same fix but using a LinkedHashMap instead of a HashMap to store the cycleParticipants. This is because HashMap does not always maintain the insertion order and so the tests were failing or passing at random on subsequent runs (The error string would sometime say P1, P2, P3 and the other times would say P3, P1, P2). Fixed the problem with this patch.
Ok, listing the project involved in the cycle is good enough for 3.7. However I would not change the actual way to compute the cycle. I would add a method on JavaProject called getCycle() that returns a string representation of the cycle.
(In reply to comment #15) > However I would not change the actual way to compute the cycle. Are you referring to using LinkedHashSet in place of HashSet? I didn't change the way to compute the cycle at all. Just changed the way to store it in a consistent way everytime. > I would add a method on JavaProject called getCycle() that returns a string > representation of the cycle. How will that method find out the projects that constitute the cycle? From the cycleParticipants hashSet, no? Or does it recalculate all the cycle elements? If the former is the answer, then again we might end up printing, say {P3, P2, P1} or {P1, P2, P3} on random occasions. If the latter is the answer, I don't understand why to repeat the work already done. Let me know what you think.
Agree. For now we can use a LinkedHashSet to guarantee the iteration order. +1 for your patch.
Released in HEAD for 3.7RC1.
Verified in I20110505-0800.
