This is as much a question about the use of maven <dependencymanagement>
section as much as it is about how and EAR module should play out.
I have a typical use case. Following are the maven modules
- parent
- api
- ejb
- web
- ear
ear has api
, ejb
and web
listed as its dependencies and inherits from parent
like the other modules.
Here is the dependency management section for parent
.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>3.4</version>
</dependency>
</dependencyManagement>
and for ejb
I have a dependency (not under dependency management section but a dependency) with an explicit override of the version.
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>2.5</version>
</dependency>
When I build the whole project from the parent (since they are aggregated in the parent pom), the EAR project creates the end EAR artificat.
So far so good, but the problem arises in the way the dependencies resolve. My instinct would be that because the ejb module lists spring core version 2.5 explicitly, that would get packaged as the dependency. But what actually happens is that the EAR module being a child of the parent pom uses the version mentioned in the dependency management section of the parent and ends up taking 3.4 as the spring core version.
After a lot of study I was convinced that this is as per the Maven documentation. But what I now think about is if I combine the strategy of having the parent pom controlling all dependency versions with the strategy of the EAR module inheriting the parent, I am essentially 'stuck' with (in some cases) what the parent defines with no chance to override it.
Although one could argue that one should ideally have the same version of the jar throughout, there are some situations you run into where you would like to override some dependency versions.
What is the correct approach to let me be able to override a version? The use of spring in this example is just for example purposes. It could be any other jar.