I am trying to exclude javax.persistence from javaee-api maven dependency
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
</exclusion>
</exclusions>
</dependency>
But even after adding the exclusion I still have the javax.persistence package in the javaee-api-7.0.jar
A dependency exclusion excludes a jar from the resolution of the artifact.
It means that the dependency (jar) will not be transitively pulled during the build.
In your case, it means this dependency:
<groupId>org.eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
will not be included in the resolution of the dependency :
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
and so will not be included in the artifact that you build.
But it doesn't mean that classes with a package that starts with javax.persistence will be removed from the jar.
The javax:javaee-api:7.0 jar will be indeed be provided with its original content.
Besides, your exclusion makes no sense.
org.eclipse.persistence:javax.persistence is not a dependency provided by javax:javaee-api.
javax:javaee-api is the Java EE API while org.eclipse.persistence:javax.persistence refers to a repackaging of the specific javax.persistence API of java EE + some extensions provided by EclipseLink.
Related
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.
I have a dependency library which is being pulled in by a library which I have included in my POM.
This transitive dependency has been flagged as an operational risk by a security scan and asked to upgrade it to the latest version. I need to understand how that can be done?
I tried excluding the library from the POM and then declare a direct dependency on the latest version of the same transitive dependency but I get classNotFound exception.
Code elaboration:-
Direct dependency -> hibernate-core
Transitive dependency which as been flagged -> ANTLR 2.7.7
The failed fix that I have tried ->
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>5.4.18.Final</version>
<exclusions>
<exclusion>
<groupId>antlr</groupId>
<artifactId>antlr</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>antlr</groupId>
<artifactId>antlr</artifactId>
<version>3.0ea8</version>
</dependency>
Please suggest a generic approach to replacing a transitive library.
There is no need for exclusions. You can override transitive dependencies in the <dependencyManagement> like:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>antlr</groupId>
<artifactId>antlr</artifactId>
<version>3.0ea8</version>
</dependency>
...
This will override all transitive occurrences of the library with the version you specify.
But this does not protect you from classNotFound exceptions. If you update a library, class names may have changed and your program might break.
I am using spring-boot 2.0.3.RELEASE. When I am clicking on "show Effective POM" option by using IntelliJ IDEA, it loads Effective POM. And there I can see a few dependencies that my client don't want to have at there side.
Is there any way to tell Maven not to include these dependencies? How can we exclude dependencies from effective poms?
Maven provides a way to exclude dependencies with the exclude tag
Here is an example taken from the documentation website https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
<dependencies>
<dependency>
<groupId>sample.ProjectA</groupId>
<artifactId>Project-A</artifactId>
<version>1.0</version>
<scope>compile</scope>
<exclusions>
<exclusion> <!-- declare the exclusion here -->
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
The idea is to locate parent dependencie from where you are getting deps you don't want and add an exclusion tag.
If they are needed in runtime you can specify the scope to provided
<dependency>
<groupId>sample.ProjectA</groupId>
<artifactId>Project-A</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
That will tell maven to use the deps to compile but not no include them in the target package, and they will be provided in the production environment by the JVM executing the code.
Hope this helps
I realised that one of my projects uses slf4j 1.5.8 and Hibernate uses slf4j 1.6. While building with Maven it downloads both jars but I guess the class files of 1.5.8 are used. So, when I run the program i get following error:
SLF4J: The requested version 1.5.8 by your slf4j binding is not compatible with [1.6]
In pom.xml I have put
<dependencyManagement>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.6.1</version>
</dependency>
</dependencyManagement>
The 1.5.8 is part of dependency so it's downloaded on its own.
As you discovered yourself, there are two libraries (Hibernate and some other) transitively importing SLF4J in two different versions. Unfortunately the older version is being picked up by maven (there are some rules which dependency should be chosen by maven in this situation). The solution is to add the exclusion in the dependency that imports older version of SLF4J (com.example:foo-bar is example here):
<dependency>
<groupId>com.example</groupId>
<artifactId>foo-bar</artifactId>
<version>1.2.3</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>
</exclusions>
</dependency>
If you still experience this problem, issue:
$ mvn dependency:tree
Look for 1.5.8 version and exclude it from all libraries importing it.
Excluding is quite unnecessary and maybe quite misleading. Instead, explicitly include the slf4j-api with the desired version in your projects pom file. That's it!
This approach takes advantage of Maven's transitivity rules: the nearest dependency declaration wins.
you can exclude the wrong version with something like this:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>3.2.7.ga</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>
</exclusions>
</dependency>
My project has the following structure with multiple jars and wars:
root (pom)
+--core (jar)
+--webapp (jar)
+--childgroup (pom)
+--actual-web-application (war)
+--some-library (jar)
+--othergroup (pom)
+--another-web-application (war)
Where actual-web-application depends on webapp which depends on core. Ideally, I would like to specify the Java EE dependency only in the webapp module and let the actual-web-application inherit it. But because it's a provided dependency, this doesn't work and I have to manually add dependencies for provided stuff like Java EE, jax-rs etc. in every web application.
Is there any way, with dependencyManagement for example, to let actual-web-application inherit the javaee-api from the webapp?
What I've tried, in webapp's pom.xml:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
</dependency>
</dependencies>
</dependencyManagement>
And in actual-web-application's pom.xml:
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<scope>provided</scope>
</dependency>
However, it complies about the version so it seems like it's still not carrying over the dependency from webapp's pom.xml.
Put <scope>provided</scope> into dependencyManagement also
Provided dependencies are inherited just as any other dependency would be.
parent pom.xml:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
</dependencyManagement>
child pom.xml:
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
</dependency>
</dependencies>
And the child's dependency tree:
--- maven-dependency-plugin:2.8:tree (default-cli) # child ---
com.iei.web:child:war:1.0-SNAPSHOT
\- javax:javaee-api:jar:7.0:provided
\- com.sun.mail:javax.mail:jar:1.5.0:provided
\- javax.activation:activation:jar:1.1:provided
If you are trying to avoid explicitly defining dependencies in the child at all, then you would of course have to move it out of dependencyManagement in the parent and make it a direct dependency, assuming you want every child module to inherit it.
Dependency Management