I was exploring archiva as the intenal maven repository manager. I need to manage dependecies.
My application is bundle of modules. I would like to manage dependencies on the basis of higher version.
For eg. Module A uses version 1 of the dependency. While module B uses version 2 of the same dependecy.
Now if a person want to use both the modules then the result should be such that the version two should get referred instead of version 1.
I think that is not a wanted behaviour. What if Version 1 and 2 are incompatible. If you have controll of both Modules A and B than its better to let them use the same version of their dependencies. I Typically declare common dependencies in the parent POM in the dependencyManagement section to so each submodule uses the same version.
Related
I have a project using various hadoop libraries, in which I want to have all dependencies from group "org.apache.hadoop" to have same version i.e. 2.7.6, for even the transitive dependencies.
E.g. hive-hcatalog-core:jar:2.3.2 - depends on hadoop-mapreduce-client-core:jar:2.7.2 , but I want 2.7.6 version of hadoop-mapreduce-client-core to be used explicitly.
Similary for many libraries within org.apache.hadoop.
Edit - I made my stuff work by adding such conflicting dependencies explicitly in my pom.But I was wondering if we could enforce something like this.
If you really want to change the transitive dependencies (see khmarbaise's comment), you can do so with <dependencyManagement>. It allows you to define the version of all dependencies, including transitive ones.
See e.g.
differences between dependencymanagement and dependencies in maven
need to add the Dependencies of spring web jar 3.1.3 and 3.2.2 in the same pom.xml.
Does maven support the same jar of different versions?
In addition to this,
Maven does that in a different way. If there are two dependency declarations with different versions, the higher version takes the precedence.
EDIT1 :
This statement is for the direct dependency declaration in the same pom. Forcing the required version to use is the strategy here.
Maven uses dependency mediation to resolve the version conflicts.
AFAIK, as the higher versions always have backward compatibility, preferred is to use the higher version.
Unless there is a very strong reason behind adding a specific version, it all goes to designing the modules and their hierarchy.
This gives you complete insight of how to manage the dependencies using modules.
This describes the conflict resolution scenarios.
EDIT2:
For the transitive dependencies, yes the nearest definition is the strategy followed. As in example.
I have to add a new dependency to a maven project. This dependency has four transitive dependencies(according to http://mvnrepository.com/) and between them, there is spring-data-jpa jar.
The maven project I am working in has many dependencies configured in the pom so I understand there could be a big possibility that there is already a spring-data-jpa dependency in the project(transitive or not).
When you work in a large project with many dependencies and you have to add a new one, how to check if there is already the same transitive dependency of a different version? I have to check manually the transitive dependencies for each direct dependency configured? Has maven a warning for this situation?
How maven works in this situation? I mean, there could be two spring-data-jpa jars of different versions(this would be a problem) or maven resolves this in another way?
The simple answer is that the dependency plugin can tell you. The longer answer is that there are a number of different situations to consider about transitive dependency management, and how the plugin helps and what to do about it differs for each one.
Maven automatically chooses which dependency to include if two dependencies have the same coordinates (groupId, artifactId) with different versions. Broadly speaking, it picks the version that's highest in the tree - effectively overriding dependencies defined in downstream transitive dependency poms. So, if you have two different versions of exactly the same dependency then you will still only find one version of the dependency on the relevant classpath.
The dependency plugin can help you identify this situation by highlighting points where its made a decision, but you probably want to use the dependencyManagement section of your top-level pom to ensure that the dependencies which you bring in are the ones you expect.
Separate difficulties can arise when a dependency changes its groupId or artifactId. Then you can get two dependencies on the classpath - one with an old version on the old coordinates and one with the new version on the new coordinates. As examples, Spring, Hibernate and Apache commons have all found themselves doing this at some point or another. In this case all you can do is use to the dependency plugin to identify duplicated dependencies and then use exclusions tags to explicitly exclude them as transitive dependencies from the dependencies which are pull them in.
It's important to note that all of this dependency management can cause unintended breakage. If the thing that your application depends on really does depend on some specific version of a package as a transitive dependency then you can break it by overriding that version. So testing the features that you use is essential.
Have you tried the Maven Dependency Plugin? There's some useful goals you can run, such as mvn dependency:tree etc.
Artifact_A has both the direct dependency and the transitive dependency on Artifact_B within the same scope.
Does the direct dependency always precede the transitive dependency, or the one of higher version prevail?
Is there any reference with better illustration on Maven Dependencies Resolution than the chapter Maven reference manual - Project Dependencies?
The dependency-resolution mechanism can be complicated. If there's a managed version (dependencyManagement), then that will take precedence. Generally speaking, Maven will use the highest-requested version that satisfies all of the requirements (for example, some servlet package might require [2.4,3.0) while another package requires 2.5, so Maven will use 2.5). If Maven can't find such a version (in the above sample, if the second package required [3.0,4.0)), then it will produce an error.
If you have a specific issue that you're running into, feel free to post a question with all the details.
I'm playing around with gradle trying to port my maven project and here's my problem:
In maven we have the <dependencyManagement> which provides a common (default) version for certain dependencies (which is used only when in a sub-pom this artifact is used without a version number). It also, from what I understand, forces a certain version for all transitive dependencies. So if I understand correctly even if artifact B which we have as a dependency has a dependency on artifact C version 1.0 then we will still use a version of artifact C defined in the <dependencyManagement> (so it might be 2.0). Is that correct?
If so then is there a way to do something similar in Gradle? I know that a common way of replacing the <dependencyManagement> is to simply create a Groovy map in one of the build scripts. But how can I force the transitive dependency version? If I use Gradle's "force" won't it affect all (not only transitive) dependencies (which is obviously not what I want)?
In Gradle, forcing a version (e.g. with Configuration.resolutionStrategy.force) will force it for all dependencies of the configuration, direct and transitive. There is no first-class feature that forces a version only for transitive dependencies. Do you have a valid use case for this? At the end of the day, both Gradle and Maven will select a single version for a dependency anyway, no matter where and how often it appears in the dependency tree.
There is a ResolutionStrategy feature that allows forcing artifacts versions including transitive dependencies: https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html
It is also possible to configure dependencies constraints: https://docs.gradle.org/current/userguide/dependency_constraints.html