The method JavaPackage.containsCycle currently returns true for packages that merely reference cyclic packages, even when they do not form part of a cycle themselves.
As an example, consider these packages with 2 small cycles:
A ---> W <=> X ---> B ---> Y <=> Z ---> C
The method would return true for all packages except C.
A more useful method would be one that returns true only for strongly connected packages. i.e. "from a package, is there any path through the graph that leads back to it?" This method would return true for W, X, Y, Z, but false for A, B and C.
Of course it is possible to implement this method externally via getEfferents(), however it would benefit more people if the method were directly available from the natural place in JavaPackage. Perhaps a new method named isWithinCycle?
I can provide a patch or pull-request if there is interest.
Motivation:
Asserting the absence of cycles is useful in unit tests to help lock-down packages once we succeed in making them cycle-free. While there are tangles however, it important to minimise the number of packages listed as being "cyclic"; since these (somewhat simple) unit-tests offer no protection for these packages. Hence it is important to rule out any 'false positives' to minimise the scope for architectural rot.
The method
JavaPackage.containsCyclecurrently returnstruefor packages that merely reference cyclic packages, even when they do not form part of a cycle themselves.As an example, consider these packages with 2 small cycles:
The method would return
truefor all packages except C.A more useful method would be one that returns
trueonly for strongly connected packages. i.e. "from a package, is there any path through the graph that leads back to it?" This method would returntruefor W, X, Y, Z, butfalsefor A, B and C.Of course it is possible to implement this method externally via
getEfferents(), however it would benefit more people if the method were directly available from the natural place inJavaPackage. Perhaps a new method namedisWithinCycle?I can provide a patch or pull-request if there is interest.
Motivation: Asserting the absence of cycles is useful in unit tests to help lock-down packages once we succeed in making them cycle-free. While there are tangles however, it important to minimise the number of packages listed as being "cyclic"; since these (somewhat simple) unit-tests offer no protection for these packages. Hence it is important to rule out any 'false positives' to minimise the scope for architectural rot.