Does exists some way to avoid duplicated JARs with distinct groupId in maven without expliciting excluding the duplicates? - maven

I have a maven build which generates some duplicated JARs in classpath.
Here are some examples:
groupId: javax.xml.stream
artifactId: stax
version: 1.0-2
groupId: stax
artifactId: stax
version: 1.0.1
groupId: jboss
artifactId: javassist
version: 3.7.0 GA
groupId: javassist
artifactId: javassist
version: 3.9.0 GA
These JARs are not imported directly from my project, they are transitive dependencies. Since the groupId and artifactId of the different versions does not matches, maven thinks that they are independent.
I can hunt down (may be using some tool for that) these duplicates and exclude them explicitly in pom.xml. However I don't want to manually hunt them down and exclude them, because this defeats the automatic dependency managing from maven and is a nightmare when some dependency is upgraded and the transistive dependencies mismatches again. There exist some way to make maven smarter and fix this automatically?

Answering that. I found no way to make maven smarter and had to hunt down and manually exclude every duplicated dependency. Switching the repositories to use a set of repositories that does not messes up one to the other helps too, but this is not always possible and can have side-effects of breaking some dependencies.

There is a workaround using the relocation mechanism, though it may only work in certain environments.
In short relocation allows you to "redirect" all dependencies from e.g. javax.xml.stream:stax to stax:stax. The problem is, adding a relocation is nothing you can do in your own project. You have to add a new version to the original groupId and artifactId containing the relocation information. If you have a private (e.g. corporate) Maven repository you can add it there or if there are only few developers the developers local repository can be used. In other cases you are probably out of luck with this solution.
Now the details:
Create a new Maven project with a pom.xml like this:
<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>
<!-- Coordinates of the artifact you want to replace -->
<groupId>javax.xml.stream</groupId>
<artifactId>stax</artifactId>
<!-- Some dummy version that would never be released -->
<version>relocate-to-stax</version>
<distributionManagement>
<relocation>
<!-- Coordinates of the new artifact -->
<groupId>stax</groupId>
<!-- artifactId stays the same → no need to specify again -->
</relocation>
</distributionManagement>
</project>
Add this to your repository (e.g. using mvn install).
In your project add this new version for the artifact to the dependencyManagement section:
<project>
<!-- ... -->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>javax.xml.stream</groupId>
<artifactId>stax</artifactId>
<version>relocate-to-stax</version>
</dependency>
</dependencies>
</dependencyManagement>
</project>
With this, all dependencies to javax.xml.stream:stax will use the "version" relocate-to-stax which will relocate to stax:stax:relocate-to-stax. The only thing left to do is to add the desired version of the destination artifact to the dependencyManagement:
<project>
<!-- ... -->
<dependencyManagement>
<dependencies>
<!-- ... -->
<dependency>
<groupId>stax</groupId>
<artifactId>stax</artifactId>
<version>1.0.1</version>
</dependency>
</dependencies>
</dependencyManagement>
</project>

Related

Maven version ranges : release vs snapshot version

With Apache Maven 3.3.9, We are using maven ranges for some dependencies version resolution as there are a lot of maven modules in my application an keeping the specific dependency version and changing to each release is bit pain.
To ilusstrate the structire of current application its like
pom.xml (parent)
<groupId>com.myapp</groupId>
<artifactId>myapp</artifactId>
<version>0.0.5-SNAPSHOT</version>
<packaging>pom</packaging>
<name>parentpom</name>
<modules>
<module>../myapp-service</module>
</modules>
<dependencies>
<dependency>
<groupId>com.someotherapp</groupId>
<artifactId>someotherappA</artifactId>
<version>[1.1.0, 1.2.0)</version>
</dependency>
<dependency>
<groupId>com.someotherapp</groupId>
<artifactId>someotherappB</artifactId>
<version>[1.1.0, 1.2.0)</version>
</dependency>
</dependencies>
pom.xml (child module)
<parent>
<groupId>com.myapp</groupId>
<artifactId>myapp</artifactId>
<version>[0.0.1,2.0.0)</version>
<relativePath>../myapp/pom.xml</relativePath>
</parent>
<groupId>com.myapp.service</groupId>
<artifactId>myapp-service</artifactId>
<version>1.0.9-SNAPSHOT</version>
<packaging>jar</packaging>
<name>myapp-service</name>
<dependencies>
<dependency>
<groupId>com.someotherapp</groupId>
<artifactId>ssomeotherappA</artifactId>
</dependency>
<dependency>
<groupId>com.someotherapp</groupId>
<artifactId>someotherappB</artifactId>
</dependency>
</dependencies>
EXPECT : I expect the child module should pick the last released dependency version(no snapshot) like someotherappA-1.2.0 and not the latest version ´someotherappA-1.2.1-SNAPSHOT´
PROBELM : If available dependency version in artifactory are like ´someotherappA-1.2.1-SNAPSHOT´(latest snapshot) and ´someotherappA-1.2.0´(stable release), then maven artifact ´myapp-service´ pick SNAPSHOT dependencies rather release version,even tough i am specifying -DallowSnapshots=false which means snapshot versions are not allowed in maven version ranges.
Here is what i am using to build my child module
mvn versions:resolve-ranges -f "myapp-service/pom.xml" -DgenerateBackupPoms=true -DallowSnapshots=false -DprocessDependencyManagement=false -DprocessParent=true
mvn clean install
I found similar problem here how do I stop maven version ranges from using snapshots and seems there is an open bug in maven https://issues.apache.org/jira/browse/MNG-3092 . However, I am looking possible workaround or solution if someone bypassed this similar problem.

Maven POM packaging with dependencies

I'm trying to construct a codebase where subsystems can be developed as maven modules, without the importing POM needing to concern itself with the internal structure of the maven module.
The "importing" pom
<project>
<artifactId>application</artifactId>
<packaging>jar</packaging>
<dependencies>
<dependency>
<artifactId>submodule-1</artifactId>
</dependency>
</dependencies>
</project>
The "imported" pom
<project>
<artifactId>submodule-1</artifactId>
<packaging>pom</packaging>
<modules>
<module>api</module>
<module>implementation</module>
</modules>
<dependencies>
<dependency>
<artifactId>api</artifactId>
</dependency>
<dependency>
<artifactId>implementation</artifactId>
</dependency>
</dependencies>
</project>
This does seem to work, at least partially; the generated JARs appear to be on the classpath during mvn package. IntelliJ shows the application has a dependency on submodule-1 and transitively on api and implementation. However, mvn dependency:tree fails while building submodule-1 saying
Could not resolve dependencies for project submodule-1:pom:1.0.0-SNAPSHOT: Could not find artifact api:jar:1.0.0-SNAPSHOT
I'm trying to determine if this is a valid pattern, that of having packaging of pom, with defined dependencies which are also defined modules in the POM.
Have I stumbled upon a working-but-not-supported edge case, or is the dependency plugin broken in some way, or I'm breaking it in some way, or something else?

Maven: How to import dependency of type pom?

I am trying to migrate a java application to maven. There are some dependencies which have been provided as jar files so far. One of these dependencies is jung2, which is available from the maven repository: mvnrepository.com
I need all of the provided modules and I do not understand how to declare this dependecy correctly in my pom.xml such that all corresponding jar files are downloaded and the classes are available at compile time.
This is what my pom.xml file looks like right now:
<?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 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>groupId</groupId>
<artifactId>myProject</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencyManagement>
<dependencies>
<!-- https://mvnrepository.com/artifact/net.sf.jung/jung2 -->
<dependency>
<groupId>net.sf.jung</groupId>
<artifactId>jung2</artifactId>
<version>2.0.1</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
</project>
I also tried leaving out <scope>import</scope> and put the dependency into the dependencies section. When executing mvn compile or mvn package, error message occur that the corresponding packages do not exist.
If I additionally add a dependency inside dependencies but outside of dependencyManagement, e.g.
<dependencies>
<dependency>
<groupId>net.sf.jung</groupId>
<artifactId>jung2</artifactId>
</dependency>
I receive an error about missing version. But as far as I understood, this should not be necessary due to dependencyManagement? If I also add <version>2.0.1</version>, then I get the following error message:
Failure to find net.sf.jung:jung2:jar:2.0.1
The dependencyManagement tag is used generally when you have a multi module project in maven (where you will have parent-child relationship).
If you specify any dependencies within the dependencyManagement tag, it would NOT actually download the dependencies.
Putting the dependency within this tag simply means that this dependency is available (to download / to use) for the child pom. The child pom will have to explicitly provide the groupId and the artifactId co-ordinates to download and use the jar to compile its classes.
If you just have a single module project (looks like yours is a single module project) then you can fix this issue by not using the dependencyManagement tag.
Simply put your jars in the dependencies tag.
For ex:
<dependencies>
<dependency>
<groupId>com.abc</groupId>
<artifactId>def</artifactId>
<version>1.0.0</version>
<type>pom</type> // This will now download the pom and its associated transitive dependent jars
</dependency>
<dependency>
<groupId>com.pqr</groupId>
<artifactId>xyz</artifactId>
<version>1.0.0</version>
<type>pom</type> // This will now download the pom and its associated transitive dependent jars
</dependency>
</dependencies>
Like I said before, the dependencyManagement tag will mostly make sense to use if you have a multi-module project, which isn't your case.

Dependencies in Dependency Management vs Dependencies in Maven versions plugin

When I use Maven versions:display-dependency-updates to check dependencies updates, I get two sections of result.
1st:
The following dependencies in Dependency Management have newer
versions:
2nd:
The following dependencies in Dependencies have newer versions:
What's the difference between these two?
The Dependency section of the POM defines the artifacts (jars, zip etc) upon which your project depends. i.e. the artifacts that it requires to compile, run etc.
The Dependency Management section of the POM is used to manage dependency information.
So for example, in the following pom the JUnit dependency is defined completely in the dependencyManagement section of the POM with version=4.11 and scope = test.
In the dependency section you simply need to define the JUnit dependency using the groupId and artifactId and maven automatically picks up the version and scope from the dependencyManagement section.
<?xml version="1.0" encoding="utf-8"?>
<project>
...
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
<scope>test</scope>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
<dependencies>
</project>
Usually you would define the dependencyManagement section in a parent POM, where you define the version and scope for all dependencies. Then in the child module's you simply need to define the dependencies using the groupId and artifactId. This allows you to centrally manage versions and means you only have to update them in one place.
All of this is far better explained in the maven documentation:
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
The Versions Maven Plugin is simply listing the versions found in each of these sections, as it is possible in the dependencies section to override the version that was defined in the dependencyManagement section.

Maven cannot resolve a jar which I can see on the repository

I specify wicket version 1.5-RC7 in my pom.xml. When I do a mvn install it complains about: The following artifacts could not be resolved: org.apache.wicket:wicket:jar:1.5-RC7, javax.transaction:jta:jar:1.0.1B. So I try searching for the javax.transaction.jta-1.0.1B.jar on mvnrepository.com, and I am able to find it. Why does maven tell me it can't resolve avax.transaction:jta:jar:1.0.1B?
My pom.xml:
<?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 http://maven.apache.org/maven-v4_0_0.xsd">
…
<repositories>
<repository>
<id>mvnrepository</id>
<url>http://repo1.maven.org/maven2</url>
</repository>
</repositories>
<dependencies>
<!-- WICKET DEPENDENCIES -->
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket</artifactId>
<version>${wicket.version}</version>
</dependency>
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket-spring</artifactId>
<version>${wicket.version}</version>
</dependency>
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket-extensions</artifactId>
<version>${wicket.version}</version>
</dependency>
…
</dependencies>
</build>
<properties>
<wicket.version>1.5-RC7</wicket.version>
...
</properties>
</project>
First, http://repo1.maven.org/maven2 is the default one that Maven will lookup. You don't need to declare it again.
Can you check, when you build, which server your Maven is trying to connect? You should see something like Downloading: http://whatever.com/path/to/dependencies.pom.
I have just checked in maven central repo, there is no org.apache.wicket:wicket:1.5-RC7. You have better to check if you have declared the correct dependency
For JTA, it is a bit tricky. For quite some Java spec JARs, because of licensing issue, the actual JAR is not available in the public central Maven repo. If you look at http://search.maven.org/#artifactdetails|javax.transaction|jta|1.0.1B|jar , you will see it only contains POM, but not the JAR.
There are some ways to solve:
If you have a Maven repo in your own company, consider getting the JAR from Sun/Oracle, and deploy it yourself
For JTA spec itself, JAR is available for newer version (1.1) . Check if it is fine for you to use to latter spec
Switch to use Geromino spec. It should be compatible. http://search.maven.org/#search|gav|1|g%3A%22geronimo-spec%22%20AND%20a%3A%22geronimo-spec-jta%22
Edit
I have missed the wicket 1.5-RC7 in my previous search. Sorry. After looking into the POM, it seems that it is not a JAR POM. org.apache.wicket:wicket:1.5-RC7 is of type POM, in which declares dependency to wicket-core artifact.
You have two ways to do:
Change your dependency to point to wicket-core (and maybe other wicket modules) instead of wicket.
Change your dependency declaration to have <type>pom</type> (because default is jar)
I am not familiar with Wicket, but I believe method 1 is preferred.
Check your ~/.m2/settings.xml, I'm guessing you have an internal company (Nexus) repo mirror/proxy setting avoiding you fetching from internet -- and this mirror is stale.
If this is the case there are two common way to fix it: fix your internal Nexus repo so it's up to date, or bypass the Nexus repo so you fetch from the internet
I had faced this issue just now and resolved it. I have seen lot of questions in stack overflow related to this . Since my resolution was slightly different I am posting this answer. .
Issue :-Failed to execute goal on project Apigee-Edge-deploy-plugin: Could not resolve dependencies for project io.apigee.build-tools.enterprise4g:Apigee-Edge-deploy-plugin:maven-plugin:1.0.0: The following artifacts could not be resolved:
Root Cause:- The Repo had the dependency jars mentioned in the project. But the dependencies in turn had other dependencies which was not present in the repo and caused this issue. I added exclusion to the dependency and it worked.
eg:-
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-metadata</artifactId>
<version>1.3</version>
<type>jar</type>
<scope>compile</scope>
<exclusions>
<exclusion>
<artifactId>woden</artifactId>
<groupId>org.apache.woden</groupId>
</exclusion>
</exclusions>
</dependency>
Reference:-
Also checkout the very good article on maven dependencies and exclusion

Resources