Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

override library version defined in parent pom

Tags:

I have defined version 4.3 in the parent pom for a library A , but in the project module specified by the child pom , version 2.5 of A is required. The issue I am facing is that both the versions are being kept and hence I am getting conflicts.

Please advise how to resolve the issue.

like image 791
Rndm Avatar asked Oct 25 '12 17:10

Rndm


People also ask

How do I override parent version in Pom?

It sounds like A version 2.5 is being included transitively by another dependency. This puts both version 4.3 and 2.5 at the same length. By explicitly defining dependency of A 2.5 in your project it will then be the nearest and override any other versions.

What happens if you don't specify version in POM xml?

of your question: If you don't specify a version there are various different outcomes: a) you will get an error... b) if you have defined the version in the dependency management of the project's parent's pom, then that version is taken. The parent of the project doesn't have to be an enclosing superproject.

How do I exclude a specific version of a dependency in Maven?

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.

How do I change the version of POM xml?

mvn scm:checkin -Dincludes=pom. xml -Dmessage="Setting version, preping for release." Then you can perform your release (I recommend the maven-release-plugin), after which you can set your new version and commit it as above. The versions plugin is your friend.


2 Answers

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

Dependency mediation - this determines what version of a dependency will be used when multiple versions of an artifact are encountered. Currently, Maven 2.0 only supports using the "nearest definition" which means that it will use the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree, until Maven 2.0.8 it was not defined which one would win, but since Maven 2.0.9 it's the order in the declaration that counts: the first declaration wins.

  • "nearest definition" means that the version used will be the closest one to your project in the tree of dependencies, eg. if dependencies for A, B, and C are defined as A -> B -> C -> D 2.0 and A -> E -> D 1.0, then D 1.0 will be used when building A because the path from A to D through E is shorter. You could explicitly add a dependency to D 2.0 in A to force the use of D 2.0

It sounds like A version 2.5 is being included transitively by another dependency. This puts both version 4.3 and 2.5 at the same length.

  • Project -> Parent -> A 4.3
  • Project -> Dependency -> A 2.5

By explicitly defining dependency of A 2.5 in your project it will then be the nearest and override any other versions.

like image 193
Adam Schreiner Avatar answered Nov 17 '22 15:11

Adam Schreiner


In general, it is recommended to have only one version of dependency in your classpath at a given time. Doing in such a way will allow you to know exactly what version of class will be used at runtime.

To avoid version conflicts try to specify your dependency like this:

<dependency>     <groupId>commons-daemon</groupId>     <artifactId>commons-daemon</artifactId>     <version>1.0.1</version>     <exclusions>         <exclusion>             <groupId>some_group</groupId>             <artifactId>some_artifact</artifactId>         </exclusion>     </exclusions> </dependency> 

Where you need to specify the groupId and artifactId of your conflicting artifact with version 2.5.

like image 43
Andrew Logvinov Avatar answered Nov 17 '22 16:11

Andrew Logvinov