Menu
Consider a testCycle parent with modules DummyCore and TestFramework.
TestFramework depends on DummyCore, and DummyCore has a test dedepency on TestFramework.
Building and testing each module independently maven has no problems. But mvn test the parents testCycle results in:
The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='com.mysimpatico:TestFramework:1.0-SNAPSHOT'}' and 'Vertex{label='org.apache:DummyCore:1.0-SNAPSHOT'}' introduces to cycle in the graph org.apache:DummyCore:1.0-SNAPSHOT --> com.mysimpatico:TestFramework:1.0-SNAPSHOT --> org.apache:DummyCore:1.0-SNAPSHOT -> [Help 1]
To see the full stack trace of the errors, re-run Maven with the -e switch.
Re-run Maven using the -X switch to enable full debug logging.
For more information about the errors and possible solutions, please read the following articles:
[Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectCycleException
To reproduce:
wget http://dp4j.sf.net/debug/testCycle.zip
unzip testCycle.zip
cd testCycle; mvn test
My expectation was that maven would build DummyCore src and then coming to compile the tests will compile TestFramework src, which doesn't depend on DummyCore. At this stage it would have compiled DummyCore src + tests, and TestFramework src. Finally it will compile DummyCore tests too. Is there a way to tell maven to do this?
If not, how would you work around this?
Move the tests in DummyCore into a module of its own that depends on DummyCore and TestFramework? I'd be doing that just to satisfy maven.
582
A simple way to break the cycle is by telling Spring to initialize one of the beans lazily. So, instead of fully initializing the bean, it will create a proxy to inject it into the other bean. The injected bean will only be fully created when it's first needed.
Analyze cyclic dependenciesFrom the main menu, select Code | Analyze Code | Cyclic Dependencies. In the Specify Cyclic Dependency Analysis Scope dialog, select the scope of files that you want to analyze. Select the Include test sources option if you want to analyze your test code together with the production code.
and, yes, cyclic dependencies are bad: They cause programs to include unnecessary functionality because things are dragged in which aren't needed. They make it a lot harder to test software. They make it a lot harder to reason about software.
Maven does not allow cyclic dependencies between projects, because otherwise it is not clear which project to build first. So you need to get rid of this cycle. One solution is the one you already mentioned, to create another project.
You can't resolve this conflict with Maven or with any other build tool. It's not a build tool issue, it is an architectural flaw and can only be addressed through refactoring.
Two options come immediately to mind:
1) Create a new module called "test_common" that contains the stuff that both TestFramework need and DummyCore need. The make test_common a dependency of both of those modules.
2) Move the stuff that TestFramework needs from DummyCore into TestFramework. Then TestFramework depends on nothing and DummyCore depends on TestFramework.
There are many ways to solve this, but circular inter-module dependencies are a big time NO-NO regardless of language or build tool.
53
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
