How to resolve "Dependency convergence error" when using maven enforcer plugin? - maven

I am just trying to pickup with maven-enforcer-plugin using a small pom (before I jump in to my project pom which has 100+ dependencies.)
After I have added the enforcer plugin, I am seeing Dependency convergence error.
The pom.xml file is below (sorry its not tidy).
How can i fix the errors with out disabling the enforcer plugin.
Basically I want to understand the concept behind how to use dependencyConvergence rule.
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.demo</groupId>
<artifactId>enforcer</artifactId>
<version>0.0.1-SNAPSHOT</version>
<dependencyManagement>
<dependencies>
<!--
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>5.2.13.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
<version>5.2.13.RELEASE</version>
</dependency>
-->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>5.2.10.RELEASE</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>5.3.5</version>
</dependency>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-web</artifactId>
<version>5.4.5</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<artifactId>maven-enforcer-plugin</artifactId>
<version>3.0.0-M3</version>
<executions>
<execution>
<id>dependency-convergence</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<dependencyConvergence/>
</rules>
</configuration>
</execution>
</executions>
<configuration>
<rules>
<dependencyConvergence />
</rules>
</configuration>
</plugin>
</plugins>
</build>
</project>
Does it mean that, I have to declare each non converging dependency in the dependencyManagement explicitly as in this version of pom.xml(added dependencies to dependencyManagement).
The problem with spring-context still exists as I have added it as direct dependency and then in the dependency management with different version.
Basically - am able to fix the error, but not able to grasp the rules crystal clear yet.
fix one - pom.xml - updated the version in dependency management to the one used explicitly. So now there is no need to give the version explicitly in dependencies. But this would require me to have access to dependencyManagment of parent pom. If my statement is right, this might not be the situation every time.
fix two pom.xml - excluded spring-context from spring-security-web and it worked. But if there are a dozen of exclusion to be done, its going to be a pain.
If this is the way to go about with the convergence rule? In an enterprise project with 100+ dependencies and 100+ of their transitive dependencies, then the Bill of Materials(BOM) is gonna be quite huge and take time to build. hhhmmm. (I agree, there is going to be more control over the versions used and using property like <xyz.version>, upgrades can be done easily).
I will very much appreciate if anyone can list down the rules involving convergence.

A dependency convergence error means that
the dependency is not in dependencyManagement
there are different versions of the dependency in the dependency tree
The typical resolution is to define an entry in dependencyManagement that resolves the issue or to import an appropriate BOM into the dependencyManagement.
This is best done in the main POM of a multi module project, but also possible in modules.
Note that it is better to leave out the <version> tag in the <dependencies> section so that dependencyManagement will be used everywhere.

Related

Liferay 6.2 is not deploying my jar files

I need to modify and deploy some liferay modules that I didn't write. The original developer is not with the company anymore and there's almost no documentation on the code. The project is structured differently to the liferay projects I'm familiar with, so I'm struggling with the deployment.
It's a maven project with a number of modules, and when I build it generates multiple jar files. When I copy one of those jar files to my local deployment folder Liferay prints something like:
13:07:23,201 INFO [com.liferay.portal.kernel.deploy.auto.AutoDeployScanner][ModuleAutoDeployListener:70] Module for /Users/ali/LIFERAY/liferay-portal-6.2-ee-sp14/deploy/com.monator.ehp.routes.servicemix.moci-1.6.1.jar copied successfully. Deployment will start in a few seconds.
... and then nothing. If I check the liferay/data/osgi/modules/ directory I do see the jar file is present there, however when I test the behaviour I do not see my changes reflected, even after restarting the tomcat server.
We're running Liferay 6.2 ee sp14 with tomcat and postgres. I believe the modules in question are osgi modules, but I don't think that changes the deployment method?
EDIT: This is the main project pom file, running "mvn install" in the same directory does not create a war file, but does create multiple individual jar files in the various child module folders:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.monator.tools</groupId>
<artifactId>monator-parent</artifactId>
<version>0.7.0</version>
</parent>
<groupId>com.monator.clients.moh</groupId>
<artifactId>camel-routes</artifactId>
<version>1.6.1</version>
<packaging>pom</packaging>
<name>Camel Route Project Parent</name>
<scm>
<url>https://bitbucket.org/monator/ehealth-portal-camel-routes.git</url>
<connection>scm:git:ssh://git#bitbucket.org/monator/ehealth-portal-camel-routes.git</connection>
<developerConnection>scm:git:ssh://git#bitbucket.org/monator/ehealth-portal-camel-routes.git</developerConnection>
</scm>
<modules>
<module>servicemix.routes.parent</module>
<module>liferay.routes.parent</module>
</modules>
<properties>
<camel.version>2.13.2</camel.version>
<osgi.export.package></osgi.export.package>
<osgi.import.package>*</osgi.import.package>
<osgi.bundle.symbolic.name>${project.groupId}.${project.artifactId}</osgi.bundle.symbolic.name>
</properties>
<build>
<finalName>${osgi.bundle.symbolic.name}-${project.version}</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.7</version>
<configuration>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.4.0</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-SymbolicName>${osgi.bundle.symbolic.name}</Bundle-SymbolicName>
<Export-Package>${osgi.export.package}</Export-Package>
<Import-Package>${osgi.import.package}</Import-Package>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
<!-- Dependencies only declared for IDE support -->
<dependencies>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-core</artifactId>
<version>${camel.version}</version>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-blueprint</artifactId>
<version>${camel.version}</version>
</dependency>
<dependency>
<groupId>org.apache.aries.blueprint</groupId>
<artifactId>org.apache.aries.blueprint.cm</artifactId>
<version>1.0.5</version>
</dependency>
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-osgi</artifactId>
<version>5.10.0</version>
<!-- Since we're using Maven 3, this is necessary. -->
<exclusions>
<exclusion>
<groupId>com.sun.jdmk</groupId>
<artifactId>jmxtools</artifactId>
</exclusion>
<exclusion>
<groupId>com.sun.jmx</groupId>
<artifactId>jmxri</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</project>```
Liferay 6.x can deploy war files, not jars!
Maybe your maven projects builds many jars for then build a war file?
Better if you post the pom.xml and the internet crew try to understand the mistery..
EDIT:
This project build osgi jars for Apache Camel to create some custom routes! https://camel.apache.org/ , there are not Liferay modules!
(Maybe Liferay plays as Camel consumer/producer?)

Conflict problem building the Spring boot application

I have a problem building the spring boot application. We need to build the project with the 'lib/bin/conf' structure using the maven. I did it with another project and there is no problem. But now, a conflict occurred and an action is recommended.
Description:
An attempt was made to call a method that does not exist. The attempt was made from the following location:
org.springframework.context.support.GenericApplicationContext.setApplicationStartup(GenericApplicationContext.java:165)
The following method did not exist:
'void org.springframework.beans.factory.support.DefaultListableBeanFactory.setApplicationStartup(org.springframework.core.metrics.ApplicationStartup)'
The method's class, org.springframework.beans.factory.support.DefaultListableBeanFactory, is available from the following locations:
jar:file:/target/OrderManager/libs/communication-latest.jar!/org/springframework/beans/factory/support/DefaultListableBeanFactory.class
jar:file:target/OrderManager/libs/spring-beans-5.3.8.jar!/org/springframework/beans/factory/support/DefaultListableBeanFactory.class
The class hierarchy was loaded from the following locations:
org.springframework.beans.factory.support.DefaultListableBeanFactory: file:target/OrderManager/libs/communication-latest.jar
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory: file:target/OrderManager/libs/communication-latest.jar
org.springframework.beans.factory.support.AbstractBeanFactory: file:target/OrderManager/libs/communication-latest.jar
org.springframework.beans.factory.support.FactoryBeanRegistrySupport: file:target/OrderManager/libs/communication-latest.jar
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry: file:target/OrderManager/libs/communication-latest.jar
org.springframework.core.SimpleAliasRegistry: file:target/OrderManager/libs/communication-latest.jar
Action:
Correct the classpath of your application so that it contains a single, compatible version of org.springframework.beans.factory.support.DefaultListableBeanFactory
How can I solve this problem? I'm using a lib named communication that is provided by our company.
This is my pom file.
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.5.2</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<groupId>com.example.artifact</groupId>
<artifactId>ordermanager</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>Order Manager Component</name>
<properties>
<java.version>11</java.version>
<spring-cloud.version>Hoxton.SR7</spring-cloud.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
<version>2.4.2</version>
</dependency>
<dependency>
<groupId>com.excample.myArtifact</groupId>
<artifactId>communication</artifactId>
<version>latest</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>appassembler-maven-plugin</artifactId>
<version>2.1.0</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>assemble</goal>
</goals>
</execution>
</executions>
<configuration>
<assembleDirectory>target/OrderManager</assembleDirectory>
<repositoryName>libs</repositoryName>
<configurationDirectory>conf</configurationDirectory>
<configurationSourceDirectory>src/main/resources</configurationSourceDirectory>
<copyConfigurationDirectory>true</copyConfigurationDirectory>
<repositoryLayout>flat</repositoryLayout>
<useWildcardClassPath>true</useWildcardClassPath>
<programs>
<program>
<mainClass>com.example.artifact.ordermanager.OrderManagerComponentApplication</mainClass>
<id>OrderManager</id>
</program>
</programs>
</configuration>
</plugin>
</plugins>
</build>
</project>
the answer is already there:
Correct the classpath of your application so that it contains a single, compatible version of org.springframework.beans.factory.support.DefaultListableBeanFactory
Your problem is, that you've got 2 JAR files containing the same class org.springframework.beans.factory.support.DefaultListableBeanFactory. These are:
/target/OrderManager/libs/communication-latest.jar
target/OrderManager/libs/spring-beans-5.3.8.jar
You have to remove one of them. Now I don't know your project and architecture, but if you're using a company customized spring library, then you should remove the standard spring jar. Use maven's exclude mechanism for that, it is a so called transient dependency, so you didn't define it explicitly, but one of the dependencies you defined is dependending on that.
First you have to find out which dependency brings that spring-beans dependency in. Use maven's dependency tree to do that:
mvn dependency:tree
You can also use dependency analysis or read about the whole dependency management.
If you want to kick out the communication-latest.jar you should just remove the following in your pom.xml:
<dependency>
<groupId>com.excample.myArtifact</groupId>
<artifactId>communication</artifactId>
<version>latest</version>
</dependency>
For resolving this conflict you can use excludes-dependencies https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
In this case, it should be
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
from
<groupId>com.excample.myArtifact</groupId>
<artifactId>communication</artifactId>
The problem was with version mismatching with the spring boot that is used in the communication library rather than the spring boot of the main project. So, I changed the spring boot version to 2.3.3.RELEASE and the problem are solved.
Some friends told me to exclude the spring-beans artifact. I did not do that and version changing was enough, But testing the approaches that are told on this topic, can be useful.

Remove test dependencies from deployed POM

I have a fairly typical pom.xml which builds a jar:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>mygroup</groupId>
<artifactId>my-lib</artifactId>
<version>1.0.0</version>
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>...</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter</artifactId>
<version>5.6.2</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.2.4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<createDependencyReducedPom>true</createDependencyReducedPom>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
I thought it'd be nice to remove the test dependencies (junit-jupiter and its dependencies) from the copy of the POM which is deployed with the jar, just to avoid imposing them on users of the jar. After all, test code isn't included in the deployed jar, so it shouldn't matter to users of the jar how the tests are written.
I figured this would be a common use case for maven-shade-plugin. But this use case doesn't seem to be mentioned in its documentation. And I wasn't able to make the shade plugin remove the junit-jupiter dependency from the reduced POM.
Is there a straightforward way to remove dependencies from the deployed POM? Am I worrying about nothing?
I saw this question, but it seems to be about removing test dependency contents from the uber jar. In my case, I'm not actually creating an uber jar. I'm just trying to use the shade plugin for its ability to rewrite the POM.
If you want to remove unnecessary parts from the deployed POM, you can use the flatten maven plugin:
https://www.mojohaus.org/flatten-maven-plugin/flatten-mojo.html
One of the features is to remove the test dependencies.

Spring boot with maven multi module project

I have a maven multi module project designed like the first answer in following SO post:
Multi-module maven with Spring Boot
Now I want a common maven module that can contain some models to be used by multiple microservices. If I make this common project as a child of the first level parent pom (so that all dependencies injected by boot like jpa, jackson etc are available to common), then STS/Spring is detecting it as a boot application and complains about no Main class on maven build.
Can someone suggest how I can achieve this?
Current Code:
parent pom.xml: (Only relevant parts included)
<project>
<name>...</name>
<groupId>...</groupId>
<artifactId>...</artifactId>
<packaging>pom</packaging>
<version>...</version>
<parent>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-parent</artifactId>
<version>Brixton.M3</version>
<relativePath />
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-jetty</artifactId>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
child (common module) pom.xml (only relevant parts), not to be boot app:
<project>
<artifactId>...</artifactId>
<version>...</version>
<name>...</name>
<parent>
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
</parent>
</project>
I don't have all the details regarding your project but my best guess is that the spring-boot-maven-plugin is defined on the parent (or you are using the spring-boot-starter-parent in your root pom). This effectively ask the build to package your module as a Spring Boot app (which is not what you want).
STS probably looks for that hint to figure out if a module contains a Spring Boot application or not. Maybe it would be nicer if it looks for a main class annotated with #EnableAutoConfiguration (or SpringBootApplication).
You can fix the problem easily (from the build side) by specifying the skip property of the repackage goal
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
If STS still picks up the module as a Spring Boot app, I'd create an issue in their tracker
Normally, Spring Boot won't start a web container if it's not present in the module.
I would suggest you to analyse your dendencies using the command
mvn dependency:tree
One more brute-force way of ensuring is use this configuration in your application.properties
spring.main.web-environment=false
Here are two ways to fix this:
You can add the skip property like #Stephane Nicoll mentioned. However, this will completely ignore the test cases inside that module. https://docs.spring.io/spring-boot/docs/current/maven-plugin/examples/it-skip.html
Another option is to add a classifier property to make a separate executable jar out of this module. https://docs.spring.io/spring-boot/docs/current/maven-plugin/examples/repackage-classifier.html
<executions>
<execution>
<id>repackage</id>
<goals>
<goal>repackage</goal>
</goals>
<configuration>
<classifier>exec</classifier>
</configuration>
</execution>
This fix will make sure the dependent module get its required jar and the source module will still be an executable one.

Maven shade plugin warning: we have a duplicate - how to fix?

This is my project POM (link to the paste, so you can right click > save as pom.xml)
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.zybnet</groupId>
<artifactId>excel-reporter</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<name>mvn1</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi</artifactId>
<version>3.8</version>
</dependency>
<dependency>
<groupId>net.sf.jasperreports</groupId>
<artifactId>jasperreports</artifactId>
<version>4.6.0</version>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>2.0.0</version>
</dependency>
</dependencies>
<build>
<resources>
<resource>
<directory>${project.build.sourceDirectory}</directory>
</resource>
</resources>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<finalName>${artifactId}-${version}-tmp</finalName>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>1.7.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<filters>
<filter>
<artifact>*:*</artifact>
<excludes>
<exclude>META-INF/*.SF</exclude>
<exclude>META-INF/*.DSA</exclude>
<exclude>META-INF/*.RSA</exclude>
</excludes>
</filter>
</filters>
<transformers>
<transformer
implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>com.zybnet.Main</mainClass>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
I followed the advice of configuring the default jar plugin as advertised in the FAQ, but still when I run mvn package about 20K warnings are issued. Running mvn clean does not help either.
According to this answer, I could manually exclude some dependencies. However, I don't know if it's the right way, and the dependency tree is rather complex so it's difficult to argue where to start.
I know that these issues are not harmful, but I'm used to treat warnings as something that must be fixed. Moreover, I'm a beginner with Maven, so I'd like to understand what's wrong with my understanding, and how to troubleshoot problems.
(Using maven assembly plugin is not an option here)
Sometimes it happens that the same class definition is found in two or more JAR files (usually these are dependency JARs). In such a case, there is nothing the developer can do except trying to figure out what to manually exclude from the dependencies or from the final artifact (maybe with the help of mvn dependency:tree -Ddetail=true). I opened an issue and submitted a patch, to help the developer with a slightly prettier output like
[WARNING] xml-apis-1.3.02.jar, xmlbeans-2.3.0.jar define 4 overlappping classes:
[WARNING] - org.w3c.dom.TypeInfo
[WARNING] - org.w3c.dom.DOMConfiguration
[WARNING] - org.w3c.dom.DOMStringList
[WARNING] - org.w3c.dom.UserDataHandler
[WARNING] maven-shade-plugin has detected that some .class files
[WARNING] are present in two or more JARs. When this happens, only
[WARNING] one single version of the class is copied in the uberjar.
[WARNING] Usually this is not harmful and you can skip these
[WARNING] warnings, otherwise try to manually exclude artifacts
[WARNING] based on mvn dependency:tree -Ddetail=true and the above
[WARNING] output
[WARNING] See http://docs.codehaus.org/display/MAVENUSER/Shade+Plugin
Using this output and that from mvn dependency:tree I added sections like
<dependency>
<groupId>net.sf.jasperreports</groupId>
<artifactId>jasperreports</artifactId>
<version>4.7.0</version>
<exclusions>
<exclusion>
<groupId>org.apache.poi</groupId>
<artifactId>poi-ooxml</artifactId>
</exclusion>
<exclusion>
<groupId>bouncycastle</groupId>
<artifactId>bcmail-jdk14</artifactId>
</exclusion>
<exclusion>
<groupId>bouncycastle</groupId>
<artifactId>bcprov-jdk14</artifactId>
</exclusion>
<exclusion>
<groupId>org.bouncycastle</groupId>
<artifactId>bctsp-jdk14</artifactId>
</exclusion>
</exclusions>
</dependency>
and managed to reduce the number of warnings from several thousands to a couple dozens. Still, this is not perfect. Still, they continue to copypaste classes that lead to name clashes (I can't understand why). Still, this solution is specific to this particular project and can't be easily ported on anything else.
As an newer update to this problem is updating to the current maven plugin.
The question is using
<version>1.7.1</version>
which will only tell you that you:
We have a duplicate org/eclipse/persistence/internal/libraries/asm/AnnotationVisitor.class in /Users/.../repository/org/eclipse/persistence/eclipselink/2.7.0/eclipselink-2.7.0.jar
Leaving you to guess or trial and error where the first entry where you have overlapping classes. Not very useful. Fortunatly,
<version>3.1.0</version>
will give you the more usefull output that includes the jars where they came from:
e.g.
annotations-3.0.1.jar, jcip-annotations-1.0.jar define 4 overlapping classes:
- net.jcip.annotations.GuardedBy
- net.jcip.annotations.NotThreadSafe
...
You can then decide to exclude one or the other, or use shade to rename the classes as appropriate to your project.
I have updated to version 3.4.1, and it works now.
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.4.1</version>

Resources