Menu
I am having trouble with understanding what happens in maven dependency tree when it states version managed from x; omitted for duplicate.
For example, let's assume that I have enterprise-data-2.4 defined in the dependency management section of server-a.
I get the following in the dependency tree of server-a for one of the dependencies server-b pulling in enterprise-data-2.4.
[INFO] +- hello.world.welcome.to:server-b:jar:3.1-SNAPSHOT:runtime
[INFO] | +- (hello.world.where.am: enterprise-data:jar:2.4:runtime - version managed from 3.0; omitted for duplicate)
Assuming server-b is the only jar pulling in enterprise-data-2.4, my understanding is that server-a will always pull in enterprise-data-2.4 here. Is this correct?
I however, have code in server-b dependent on enterprise-data-3.0 and server-b has a compile time dependency on enterprise-data-3.0.
Now, I have a test project, let's say test-b which tests server-b jar present inside server-a project and has a test dependency on enterprise-data-3.0. These tests directly hit the code present on server-a.
When I run my tests in test-b should I get errors while attempting to access functionality present in enterprise-data-3.0 since it's not being pulled in by server-a or will it pass because there is a test dependency on enterprise-data-3.0? It passes currently but I am not sure how a test dependency is sufficient.
Please help me understand.
Edit: I am using maven-3.
Thanks.
381
"Omitted for..." means that a dependency wasn't included, because it was either already included earlier, or because it conflicts with a dependency that was already included but has a different version. "Omitted for duplicate" is fine, and happens a lot.
Multiple transitive dependencies can be excluded by using the <exclusion> tag for each of the dependency you want to exclude and placing all these exclusion tags inside the <exclusions> tag in pom. xml. You will need to mention the group id and artifact id of the dependency you wish to exclude in the exclusion tag.
One way to resolve a version collision is by removing a conflicting transitive dependency from specific artifacts. In our example, we don't want to have the com. google. guava library transitively added from the project-a artifact.
Maven won't allow any other either. Build will fail if version is not found.
For example, let's assume that I have enterprise-data-2.4 defined in the dependency management section of server-a.
Then you always get 2.4 pulled in, even if there's only JARs depending on 1.8 for instance. Dependency management overrides dependency mediation.
Assuming server-b is the only jar pulling in enterprise-data-2.4, my understanding is that server-a will always pull in enterprise-data-2.4 here. Is this correct?
Assuming you have no dependency management, then yes. If there are multiple dependencies that are dependent on different versions, then it's a question of which one (and its transitive dependencies) is loaded first, as per the dependency mediation rules for Maven version > 2.0.9. Others will be: "managed from x and omitted for duplicate".
When I run my tests in test-b should I get errors while attempting to access functionality present in enterprise-data-3.0 since it's not being pulled in by server-a or will it pass because there is a test dependency on enterprise-data-3.0? It passes currently but I am not sure how a test dependency is sufficient.
If it's pulling the wrong version with incompatible code, yes you will see errors. For Maven 3, defining a test scope dependency with 3.0 and compile scope dependency with 2.4 will mean that Maven overrides the 2.4 and goes with the newer one defined on test scope. See this question and its answers for more details.
Nevertheless, you can always use dependency management in test-b to fix in the version of each dependency that you want to use.
96
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
