Develop Reference

How to exclude a transitive dependency in Maven project

I have a java spring boot application A that has dependency B which is a third party jar. B in turn has dependency C. When people need upgrade C (say from v1.0 to v2.0), a common approach is that in pom.xml of A, using Maven exclusion feature to exclude C from B, then either declare C-v2.0 as a direct dependency, or add C-v2.0 to dependencyManagement section.
This approach doesn't guarantee work in all situations. An example is org.glassfish.metro:webservices-rt:2.4.3 has dependency woodstox-core:5.1.0 which contains high security vulnerabilities and need to upgrade to 6.4.0.
My project A has (direct)dependency webservices-rt:2.4.3. Applying above approach doesn't exclude woodstox-core:5.1.0 from my project. Note: the maven dependency tree doesn't show woodstox-core:5.1.0 any more, but Aqua Scan still indicates that webservices-rt has dependency woodstox-core:5.1.0.
Below is part of my pom
<dependency>
<groupId>com.fasterxml.woodstox</groupId>
<artifactId>woodstox-core</artifactId>
<version>6.4.0</version>
</dependency>
<dependency>
<groupId>org.glassfish.metro</groupId>
<artifactId>webservices-rt</artifactId>
<version>2.4.3</version>
<exclusions>
<exclusion>
<groupId>com.fasterxml.woodstox</groupId>
<artifactId>woodstox-core</artifactId>
</exclusion>
</exclusions>
</dependency>
It seems to me that whether above approach working or not depends on how jar B is packaged. Dose anyone has knowledge to share?

The much better approach is to set the desired version in <dependencyManagement>, i.e.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.fasterxml.woodstox</groupId>
<artifactId>woodstox-core</artifactId>
<version>6.4.0</version>
</dependency>
</dependencies)
</dependencyManagement>
Then you need no exclusions at all.
If the dependency tree does not show it, it will not be used, unless the dependency is a fat jar. So, avoid fat jars as dependencies (if at all possible), and furthermore check if your Aqua Scan maybe does it wrong.

Maven: Resolve dependencies using container dependencies first

I have a plugin project which is added to other container projects as a dependency.
Now, this plugin project uses many frequent dependencies like spring-security, commons-lang, etc.
Usually, the container projects contain their own versions of such frequent dependencies. So, when we add our plugin dependency there are conflicts and the dependencies are resolved based on regular maven dependency resolver and depending on scopes and optional tags provided in the plugin project dependencies.
Is there a way where all the dependencies are resolved using the version in parent dependencies first and iff they are not available then use the version specified in plugin dependency.
Note: optional and scope runtime have a problem that these dependencies are provided by the container and thus beats the aim to provide a hassle-free single dependency to add plugin dependency.

In your plugins pom define the version of a dependency as range of the versions you know the plugin to be able to use. If a container-dependency overlaps this will be used. If no overlapping version, of the dependency both container and plugin need, can be found, an error will be produced, since the negotiation failed.
Use no special scope for the dependencies, since you want them to be included if necessary into the container,
See:
https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html
And:
https://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-project-dependencies.html#pom-relationships-sect-version-ranges

Assuming that your container and plugin projects use the same parent pom you could utilize the <dependencyManagement> section in the parent to define the common artifacts. This allows you to omit the version in the plugins <dependencies> section.
parent:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
</dependencyManagement>
plugin/module:
<dependencies>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
</dependency>
</dependencies>
See https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html for further details.

you can exclude it when you build a plugin project and add a dependency to maven.
This is an example. Dependency and main project have conflicted due to logging library. Below is to exclude log4j in dependency project.
<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<version>${zk.version}</version>
<exclusions>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
</dependency>
P/S: Added from my comments:
I have also developed a system which has a similar architecture with yours. I separate this system into 3 main parts: 1. Commons which contains common code and required maven dependencies, 2. The main project, 3. plugin project. You can refer this.

Exclude maven sub modules dependencies from top level module

I created a maven parent project with three modules :
data-layer-module
data-service-module (uses the data-layer-module)
web-module (uses the data-services-module)
Here is a snippet from the parent pom.xml :
<groupId>org.mygroup</groupId>
<artifactId>myArtifact</artifactId>
<packaging>pom</packaging>
<version>1.0-SNAPSHOT</version>
<modules>
<module>data-layer-module</module>
<module>data-service-module</module>
<module>web-module</module>
</modules>
The data-layer-module pom.xml contains no dependencies to the other modules (it contains only its external dependencies).
The data-service-module has a dependency in its pom.xml to the data-layer-module :
<dependencies>
<dependency>
<groupId>org.mygroup</groupId>
<artifactId>data-layer-module</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
And the web-module has a dependency to the data-service-module :
<dependency>
<groupId>org.mygroup</groupId>
<artifactId>data-service-module</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
Everything is fine but I don't want the web-module to have access to the data-layer-module. I need to enforce the three layer web-service-data model. Which is not the case with this configuration.
I obviously tried manually excluding it from the web-module pom.xml :
<dependency>
<groupId>org.mygroup</groupId>
<artifactId>data-service-layer</artifactId>
<version>1.0-SNAPSHOT</version>
<exclusions>
<exclusion>
<groupId>org.mygroup</groupId>
<artifactId>data-layer-module</artifactId>
</exclusion>
</exclusions>
</dependency>
But this causes compilation error since the data-service-module can't find its data-layer-module dependency.
How could this configuration be done ?

If the web module is going to run in the same jvm as the data-service-layer, then a transient dependency to the data-layer-module is necessary - this is why the exclusion you added casuses the application to fail.
You could consider making a simple api, for example data-service-layer-api, which obviously does not depend on data-layer-module, and is implemented correctly by data-service-layer.
You can still use a multi-module maven project, but now you will have 2 artifacts - a web module, and a data-service, which must be deployed separated.
It's basically a tradeoff between strict dependency analysis and project complexity.

maven dependency without version

Recently I've been working on some improvements in a project developed some time ago, and here's what I found. A lot of dependencies in the pom files go without versions specified, and yet they are resolved. The project consists of 1 root module and 2 submodules. The Aggregator pattern is used, meaning there's no dependencyManagement section at all. The upper-project simply aggregates 2 modules and that's all it does. Subprojects don't refer to it as to a parent. They have a different parent. What I can't grasp is that neither subprojects themselves nor their parent(as a matter of fact, it doesn't have dependencyManagement either) specify versions for some of the dependencies. For instance:
<dependency>
<groupId>javax.mail</groupId>
<artifactId>javax.mail-api</artifactId>
</dependency>
<dependency>
<groupId>com.sun.mail</groupId>
<artifactId>javax.mail</artifactId>
</dependency>
<dependency>
<groupId>com.sun.mail</groupId>
<artifactId>imap</artifactId>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
</dependency>
Can someone help me figure this out? Is maven handling versioning with some default strategy? What is that default strategy?

Ok, I think I'm gonna answer it myself. Of course I took a look at dependency:tree, but all the dependencies that I mentioned were first-level members of the tree. What I failed to notice right away, is that dependencyManagement is not present in the parent, but it is however present in the submodules, and what is more interesting it contains:
<dependency>
<groupId>io.spring.platform</groupId>
<artifactId>platform-bom</artifactId>
<version>1.0.2.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
I've never used Spring IO Platform before, so this is a totally new concept for me. As it turns out the platform includes quite a few preconfigured dependencies:
http://docs.spring.io/platform/docs/current/reference/htmlsingle/#appendix-dependency-versions

It is impossible for maven to work without defining versions of the artifacts. They should be defined somewhere in dependencyManagement tag either in the submodule or parent. Please check your pom hierarchy. Use mvn help:effective-pom in the submodule directory of the project. Also you can use mvn dependency:tree in order to find out which artifacts - along with full artifact information including version numbers - are resolved in the result of dependency management.

Use
mvn -P<my_profile_of_interest> help:effective-pom -Dverbose
Verbose mode (Since: 3.2.0) adds XML comments containing precise reference to a place where dependency declaration is coming from.

Each maven dependency defined in the pom must have a version either directly or indirectly for example, through dependencyManagement or parent. That being said, if the version is not given, then the version provided in the dependencyManagement or the parent pom will be used.
For example: in the pom (only important sections are mentioned) given below, no version is provided for the artifact jstl. However, in the "mvn dependency:tree", it shows that jstl version 1.2 is included. And looking at the spring-boot-starter-parent, for the version 2.3.3.RELEASE pom, it includes jstl version 1.2.
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.3.3.RELEASE</version>
</parent>
<dependencies>
....
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
</dependency>
....
</dependencies>

In my case if i was using Spring boot starter parent to manage all dependency and lombok version is managed by Spring boot , This problem was coming due to higher java version JAVA 11 . I exported JAVA 8 in to my compile time environment and after using JAVA 8 this problem was gone.

Maven retains older version of asm in repository

Initially, I had the maven dependency for asm version 3.2 in pom.xml file of my project. I update the same to version 4.1 using the following dependency
<dependency>
<groupId>org.ow2.asm</groupId>
<artifactId>asm</artifactId>
<version>4.1</version>
<scope>compile</scope>
</dependency>
but now my project has both jar files in WEB-INF/lib - asm 3.2 and asm 4.1. I need some features of asm 4.1 but due to both jars being available asm 3.2 code is used because of which I cannot use the asm 4.1 feature.
Any help in this matter is appreciated.

The dependency for asm 3.2 is:
<dependency>
<groupId>asm</groupId>
<artifactId>asm</artifactId>
<version>3.2</version>
</dependency>
Note the group IDs do not match. What is likely happening is that another of your dependencies is loading asm 3.2 as a transitive dependency. Maven's dependency resolution process cannot determine that the 4.1 version is supposed to override the 3.2 version due to the group ID difference, and there is a problem.
What you need to do is eliminate the 3.2 version. First figure out which dependency is causing Maven to pull it in, by running mvn dependency:tree or using the Eclipse POM editor's dependency hierarchy tab. Then find that dependency in your POM and add an exclusion:
<dependency>
<groupId>some.group.id</groupId>
<artifactId>dependency-pulling-in-asm</artifactId>
<version>1.0</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>asm</groupId>
<artifactId>asm</artifactId>
</exclusion>
</exclusions>
</dependency>
Maven documentation explains this further.

Give the following command after updating pom.xml
mvn clean