I am well aware of the fact that this is not good idea, but I need to define a dependency with multiple versions. I would also like to know if it is possible to resolve all transitive dependencies of such diamond dependencies. For example, if two dependencies of the project each have a dependency on commons-lang (2.1 and 3.0) and the project itself defines version 2.5, I would like to be able to download all three versions along with their transitive dependencies. Is this at all possible and how can I do it?
To answer my own question, "yes", as shown below:
<ivy-module version="2.0">
<info organisation="com.foo"
module="diamond-dependency"
revision="1.0-SNAPSHOT"/>
<dependencies>
<dependency org="javax.activation" name="activation" rev="1.1-rev-1"/>
<dependency org="org.apache.commons" name="commons-email" rev="1.3.1"/>
<conflict manager="all"/>
</dependencies>
</ivy-module>
The key bit is in the conflict manager section which, in this case, is being told to resolve all conflicting dependencies.
The above will have a dependency tree looking like this (containing three different versions of javax.activation:activation:
+- javax.activation:activation:jar:1.1-rev-1:compile
\- org.apache.commons:commons-email:jar:1.3.1:compile
+- javax.mail:mail:jar:1.4.5:compile
| \- (javax.activation:activation:jar:1.1:compile - omitted for conflict with 1.1-rev-1)
\- (javax.activation:activation:jar:1.1.1:compile - omitted for conflict with 1.1-rev-1)
Related
I just finished converting one of our in-house framework projects from ant to maven. The maven build runs fine, and deploys to our repository with no issues.
The problem is when other projects try to consume the framework, it does not work. The only thing downloaded is top level framework pom.
I have tried adding some dependency entries to one or more of the various modules, but no matter which one I add, I get a circular dependency error. I also tried creating a 2nd top level pom file with no modules and a few dependencies to overwrite the one in the repository manager. This causes some of the dependencies to be downloaded, but then the maven build will hang in random places. based on windows task manager, it looks like its in an endless loop. So a 2nd pom file does not appear to be the answer (or im doing it wrong).
my framework pom file looks something like this:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>framework_snt</groupId>
<artifactId>SFP</artifactId>
<packaging>pom</packaging>
<name>SFP framework</name>
<version>6.3</version>
<modules>
.... 50+ modules here
</modules>
and then the usual properties, dependency management and pluginManagement entries for a top level pom.
in the consuming module I just have the following:
<dependency>
<groupId>framework_snt</groupId>
<artifactId>SFP</artifactId>
<version>6.3</version>
<type>pom</type>
</dependency>
This is in the top level pom so all submodules have access to the framework libraries to make it easier on the developers.
How do I set things up so so all the dependent jar files will be downloaded by my consuming projects ?
It sounds like your framework project produces several jar artifacts, one for each child module, but no jar artifact for the parent project. Thus, declaring a dependency on the parent project's pom is not what you want to do. Instead you need to declare a dependency on each of your framework project's child modules.
I have a similar setup where I have a "toolkit" project with several modules (each producing a jar artifact). Then in my other projects I declare dependencies on whatever modules I need to use. I do not, however, declare a dependency on my "toolkit" parent projects pom file. Instead I just declare dependencies on the child modules jar artifacts.
<dependency>
<groupId>com.mycompany.toolkits</groupId>
<artifactId>file-utils</artifactId>
<version>1.0.0</version>
</dependency>
Notice that my dependency declaration points to one of my child module's and does not declare <type>pom</type> like you did. If you wanted to be really explicit you could declare <type>jar</type> instead.
The framework pom as you call it is the parent pom of your multi-module project.
While the modules can depend on each other, it cannot depend on this parent pom. This is what is possibly causing the circular dependency.
You will need to relook at your modules and identify which modules depend on which and suitably specify the dependencies. Also, these dependencies are typically jar dependencies - a packaging which will contain sources and resources.
Maven By Example is one of the many resources available which gives further information.
Here's my generic problem:
My project P depends on A which depends on B which depends on C which depends on version 1.0.1 of D.
There's a problem with version 1.0.1 of D and I want to force the use of another module. I don't know how to declare this in my project's POMs since I haven't added a dependency on D directly. It's C which declared the dependency on D.
Important: In this case, not only the version is changed, but the group & artifact as well. So it's not just a matter of overriding the version of the dependency, but rather, of excluding a module and including another one.
In the concrete case, D is StAX whose 1.0.1 has a bug. According to the notes in the bug, "the problems were solved by replacing the stax-api-1.0.1 (maven GroupId = stax) by stax-api-1.0-2 (maven GroupId = javax.xml.stream)" so I'm trying just that.
Thus, D = stax:stax-api:jar:1.0.1 and C = org.apache.xmlbeans:xmlbeans:jar:2.3.0
I'm using maven 2.0.9 in case it matters.
Output of mvn dependency:tree"
mvn dependency:tree
[..snip..]
[INFO] +- org.apache.poi:poi-ooxml:jar:3.6:compile
[INFO] | +- org.apache.poi:poi-ooxml-schemas:jar:3.6:compile
[INFO] | | +- org.apache.xmlbeans:xmlbeans:jar:2.3.0:compile
[INFO] | | | \- stax:stax-api:jar:1.0.1:compile
In my project's POM I have the following dependency on "A":
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi</artifactId>
<version>3.6</version>
</dependency>
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi-ooxml</artifactId>
<version>3.6</version>
</dependency>
Simply specify the version in your current pom. The version specified here will override other.
Forcing a version
A version will always be honoured if it is declared in the current POM with a particular version - however, it should be noted that this will also affect other poms downstream if it is itself depended on using transitive dependencies.
Resources :
Dependency Mediation and Conflict Resolution
Introduction to the Dependency Mechanism
Alternatively, you can just exclude the dependency that you don't want. STAX is included in JDK 1.6, so if you're using 1.6 you can just exclude it entirely.
My example below is slightly wrong for you - you only need one of the two exclusions but I'm not quite sure which one. There are other versions of Stax floating about, in my example below I was importing A which imported B which imported C & D which each (through yet more transitive dependencies) imported different versions of Stax. So in my dependency on 'A', I excluded both versions of Stax.
<dependency>
<groupId>a.group</groupId>
<artifactId>a.artifact</artifactId>
<version>a.version</version>
<exclusions>
<!-- STAX comes with Java 1.6 -->
<exclusion>
<groupId>javax.xml.stream</groupId>
<artifactId>stax-api</artifactId>
</exclusion>
<exclusion>
<groupId>stax</groupId>
<artifactId>stax-api</artifactId>
</exclusion>
</exclusions>
<dependency>
What you put inside the </dependencies> tag of the root pom will be included by all child modules of the root pom. If all your modules use that dependency, this is the way to go.
However, if only 3 out of 10 of your child modules use some dependency, you do not want this dependency to be included in all your child modules. In that case, you can just put the dependency inside the </dependencyManagement>. This will make sure that any child module that needs the dependency must declare it in their own pom file, but they will use the same version of that dependency as specified in your </dependencyManagement> tag.
You can also use the </dependencyManagement> to modify the version used in transitive dependencies, because the version declared in the upper most pom file is the one that will be used. This can be useful if your project A includes an external project B v1.0 that includes another external project C v1.0. Sometimes it happens that a security breach is found in project C v1.0 which is corrected in v1.1, but the developers of B are slow to update their project to use v1.1 of C. In that case, you can simply declare a dependency on C v1.1 in your project's root pom inside `, and everything will be good (assuming that B v1.0 will still be able to compile with C v1.1).
I also had trouble overruling a dependency in a third party library. I used scot's approach with the exclusion but I also added the dependency with the newer version in the pom. (I used Maven 3.3.3)
So for the stAX example it would look like this:
<dependency>
<groupId>a.group</groupId>
<artifactId>a.artifact</artifactId>
<version>a.version</version>
<exclusions>
<!-- STAX comes with Java 1.6 -->
<exclusion>
<artifactId>stax-api</artifactId>
<groupId>javax.xml.stream</groupId>
</exclusion>
<exclusion>
<artifactId>stax-api</artifactId>
<groupId>stax</groupId>
</exclusion>
</exclusions>
<dependency>
<dependency>
<groupId>javax.xml.stream</groupId>
<artifactId>stax-api</artifactId>
<version>1.0-2</version>
</dependency>
The accepted answer is correct but I'd like to add my two cents. I've run into a problem where I had a project A that had a project B as a dependency. Both projects use slf4j but project B uses log4j while project A uses logback.
Project B uses slf4j 1.6.1, while project A uses slf4j 1.7.5 (due to the already included logback 1.2.3 dependency).
The problem: Project A couldn't find a function that exists on slf4j 1.7.5, after checking eclipe's dependency hierarchy tab I found out that during build it was using slf4j 1.6.1 from project B, instead of using logback's slf4j 1.7.5.
I solved the issue by changing the order of the dependencies on project A pom, when I moved project B entry below the logback entry then maven started to build the project using slf4j 1.7.5.
Edit:
Adding the slf4j 1.7.5 dependency before Project B dependency worked too.
We have a mother-ship project with several modules:
foo
+ foo-core
+ foo-resource
+ foo-util
+ foo-whatever
I want to allow developers to include the core, resource, and util modules as dependencies (excluding the -whatever module). I know that I can specify that they include each dependency, but it would be nice to allow for them to just specify something like
<artifactId>foo-sdk</artifactId>
And get everything that they need to develop a foo. This has the added advantage that it gives us the power to add (or remove) what goes into the sdk.
It would be best if foo-sdk was not just a jar with the other jars jammed in it. I'd rather it be a pom that simply points to the other artifacts.
I feel like I've seen this done before but can't find instructions to do it. I checked out Maven Assembly Plugin but it doesn't look like this is its intended use.
You can group dependencies in a project with a packaging of type pom. From the Maven book:
3.6.1. Grouping Dependencies
If you have a set of dependencies
which are logically grouped together.
You can create a project with pom
packaging that groups dependencies
together. For example, let's assume
that your application uses Hibernate,
a popular Object-Relational mapping
framework. Every project which uses
Hibernate might also have a dependency
on the Spring Framework and a MySQL
JDBC driver. Instead of having to
include these dependencies in every
project that uses Hibernate, Spring,
and MySQL you could create a special
POM that does nothing more than
declare a set of common dependencies.
You could create a project called
persistence-deps (short for
Persistence Dependencies), and have
every project that needs to do
persistence depend on this convenience
project:
Example 3.11. Consolidating Dependencies in a Single POM Project
<project>
<groupId>org.sonatype.mavenbook</groupId>
<artifactId>persistence-deps</artifactId>
<version>1.0</version>
<packaging>pom</packaging>
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>${hibernateVersion}</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-annotations</artifactId>
<version>${hibernateAnnotationsVersion}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-hibernate3</artifactId>
<version>${springVersion}</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>${mysqlVersion}</version>
</dependency>
</dependencies>
<properties>
<mysqlVersion>(5.1,)</mysqlVersion>
<springVersion>(2.0.6,)</springVersion>
<hibernateVersion>3.2.5.ga</hibernateVersion>
<hibernateAnnotationsVersion>3.3.0.ga</hibernateAnnotationsVersion>
</properties>
</project>
If you create this project in a
directory named persistence-deps, all
you need to do is create this
pom.xml and run mvn install. Since
the packaging type is pom, this POM
is installed in your local repository.
You can now add this project as a
dependency and all of its dependencies
will be added as transitive
dependencies to your project. When you
declare a dependency on this
persistence-deps project, don't
forget to specify the dependency type
as pom.
Example 3.12. Declaring a Dependency on a POM
<project>
<description>This is a project requiring JDBC</description>
...
<dependencies>
...
<dependency>
<groupId>org.sonatype.mavenbook</groupId>
<artifactId>persistence-deps</artifactId>
<version>1.0</version>
<type>pom</type>
</dependency>
</dependencies>
</project>
If you later decide to switch to a
different JDBC driver (for example,
JTDS), just replace the dependencies
in the persistence-deps project to use
net.sourceforge.jtds:jtds instead of
mysql:mysql-java-connector and update
the version number. All projects
depending on persistence-deps will use
JTDS if they decide to update to the
newer version. Consolidating related
dependencies is a good way to cut down
on the length of pom.xml files that
start having to depend on a large
number of dependencies. If you need to
share a large number of dependencies
between projects, you could also just
establish parent-child relationships
between projects and refactor all
common dependencies to the parent
project, but the disadvantage of the
parent-child approach is that a
project can have only one parent.
Sometimes it makes more sense to group
similar dependencies together and
reference a pom dependency. This way,
your project can reference as many of
these consolidated dependency POMs as
it needs. Note
Maven uses the depth of a dependency
in the tree when resolving conflicts
using a nearest-wins approach. Using
the dependency grouping technique
above pushes those dependencies one
level down in the tree. Keep this in
mind when choosing between grouping in
a pom or using dependencyManagement
in a parent POM
Wouldn't this just be another sub-module foo-sdk with packaging pom and dependencies on foo-{core,resource,util}?
I have the following dependency specified in my project's POM:
<dependency>
<groupId>org.jboss.client</groupId>
<artifactId>jbossall-client</artifactId>
<scope>compile</scope>
</dependency>
My project itself has to be the child of another POM. And in that one, the following is defined:
<dependency>
<groupId>org.jboss.client</groupId>
<artifactId>jbossall-client</artifactId>
<version>4.2.3.GA</version>
<scope>provided</scope>
<type>jar</type>
</dependency>
When I now assembly my program, it seems that the "provided" scope of the parent POM overrides the scope of my project, since the jbossall-client.jar is not included in my assembly. Although it seems illogical to me, maybe it's this feature taking effect here.
Do you know a way to include the dependency in my assembly without touching the parent POM?
Edit:
Output of mvn dependency-tree (Updated!):
[dependency:tree]
com.myproject:myproject:jar:0.0.1-SNAPSHOT
+- com.myproject-commons:jar:1.0-SNAPSHOT:compile
| +- commons-logging:commons-logging:jar:1.0.4:compile
| +- log4j:log4j:jar:1.2.14:compile
| +- sv.seucc:seucc-unicode:jar:1.0.1.5:compile
| +- commons-lang:commons-lang:jar:2.2:compile
| +- com.thoughtworks.xstream:xstream:jar:1.2.1:compile
| \- xpp3:xpp3_min:jar:1.1.3.4.O:compile
+- com.myproject-interfaces2:jar:1.0-SNAPSHOT:compile
| \- com.myproject-service-commons:jar:1.0-SNAPSHOT:compile
+- org.springframework:spring:jar:2.5.6:compile
+- commons-io:commons-io:jar:1.3.1:compile
+- com.myproject-modules:ejb:1.0-SNAPSHOT:compile
\- org.jboss.client:jbossall-client:jar:4.2.3.GA:compile
Edit 2: Here the dependency part of my assembly XML.
<dependencySets>
<dependencySet>
<outputDirectory>lib</outputDirectory>
</dependencySet>
</dependencySets>
Edit 3: Here are the files in the lib folder of my obtained assembly.
commons-io-1.3.1.jar
commons-lang-2.2.jar
commons-logging-1.0.4.jar
log4j-1.2.14.jar
seucc-unicode-1.0.1.5.jar
spring-2.5.6.jar
xpp3_min-1.1.3.4.O.jar
xstream-1.2.1.jar
myproject-commons-1.0-SNAPSHOT.jar
myproject-modules-1.0-SNAPSHOT.jar
myproject-service-commons-1.0-SNAPSHOT.jar
myproject-interfaces2-1.0-SNAPSHOT.jar
myproject-0.0.1-SNAPSHOT.jar
Edit 4: For the answer to this question see the final comments of the correct answer.
Both dependencies don't have the same groupId so nothing get overridden here, they are treated as distinct artifacts. But I wonder how things work in your child pom (since the jbossall-client doesn't have any version). Do you have a dependencyManagement section?
Anyway, to "debug" this kind of problem, use mvn dependency:tree in your child project (and post the output if you need more help).
Update: The above was my answer to the initial question and does not reflect the current state of the question.
For the sake of clarity, the key of the final solution was to declare a <scope>compile</scope> (which defaults to runtime) in the dependencySet element of the assembly descriptor. See the comments for all details.
See also
8.5.4.3. Including and Excluding Dependencies by Scope
We had the same issue and solved it by adding a 2nd dependencySet of scope provided, BUT this only worked once we upgraded to version 2.2.1 of the assembly plugin.
Does anyone know of a way to set a specific classpath order in Maven2, rather than the random ordering I appear to experience at the moment?
There are a number of legitimate reasons for wanting to do this:
A vendor has supplied a patch jar, which contains overriding classes for a previously released jar and therefore the patch jar must appear first in the classpath ordering.
Two jar's found on the classpath discovered by traversing pom dependencies contain the same class in the same package with different signitures. For example:
jboss
jbossall-client
4.2.0.GA
org.hibernate
hibernate
3.1
both contain:
org.hibernate.util.ReflectHelper.class, but the jbossall-client version is missing the getFastClass method.
From googling I see that this is perhaps a point of contention between maven enthusiasts and people facing this particular issue, but surely there are legitimate reasons for classpath ordering.
Any advice from anyone that has solved this particular quandary would be much appreciated!
Thanks
As of version 2.0.9 maven uses pom order for classpath, so you can actually manipulate it now. We mostly supress transitive dependencies to external libraries that we also include directly.
From the release notes of maven 2.0.9:
MNG-1412 / MNG-3111 introduced deterministic ordering of dependencies on the classpath. In the past, natural set ordering was used and this lead to odd results. The ordering is now preserved from your pom, with dependencies added by inheritence added last. In builds that had conflicting or duplicate dependencies, this may introduce a change to the output. In short, if you have weird issues with 2.0.9, take a look at the dependencies to see if you have conflicts somewhere.
Maven 2.0.9 adds correct ordering so you absolutely must have that version or higher for the below to work.
Secondly you need the an updated plugin. The Maven guys are working on a fix, its in their jira to fix but this is something I urgently needed. So in the meantime I have fixed this myself and you can pull the Modified plugin source code from github.
Edit: Refer to http://jira.codehaus.org/browse/MECLIPSE-388
There are two ways to install it, either pull my modified code and install it or download the prebuilt jar and just add it.
Building the plugin
Run maven install from the plugin directory you checked out and then add the following in your plugins section of your projects pom:
<build>
</plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<version>2.8-cpfix</version>
</plugin>
</plugins>
</build>
Download the jar
Alternatively if you don't want to download and compile yourself then you can just get hold of the jar file and install it yourself.
Once you have the file run
mvn install:install-file -Dfile=<path-to-file> -DgroupId=org.apache.maven.plugins \
-DartifactId=maven-eclipse-plugin -Dversion=2.8-cpfix -Dpackaging=jar
Regardless of how you installed it now when you run mvn eclipse:eclipse it will pick up the modified code and order the dependencies based on the order you defined in your pom file, no alphabetical ordering. It will also put the JRE container at the top of the dependencies.
Hopefully the real version of this code will come out soon, but in the meantime this fix has worked for me on my project and I hope it can help some others as well.
Rather a further qualification of the question than an answer:
under "Maven Dependencies" Eclipse does not seem to honour the POM-order.
(it does use the POM-order under "Java Build Path" & in the Classpath)
Is that the expected behaviour?
I'm using Eclipse 2021-09 (which has Maven 3.8.1 embedded) under Windows 10.
Here's the POM:
<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.group</groupId>
<artifactId>arty.fact</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>Maven Dependency Order</name>
<properties>
<maven.compiler.target>17</maven.compiler.target>
<maven.compiler.source>17</maven.compiler.source>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>wsdl4j</groupId>
<artifactId>wsdl4j</artifactId>
<version>1.6.3</version>
<exclusions><exclusion><groupId>*</groupId><artifactId>*</artifactId></exclusion></exclusions>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.14.1</version>
<exclusions><exclusion><groupId>*</groupId><artifactId>*</artifactId></exclusion></exclusions>
</dependency>
</dependencies>
</project>
The Maven Dependencies looks like this:
If you have problem starting with IntelliJ IDEA, you can change the dependencies order from project structrue.