I have a question about exclusion of maven dependencies. Consider the following
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-taglibs</artifactId>
<version>${spring-security.version}</version>
<exclusions>
<exclusion>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-web</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-web</artifactId>
<version>3.1.0.RELEASE</version>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>3.1.0.RELEASE</version>
</dependency>
<dependency>
I am trying to achieve a transition from Spring 3.0.6 to 3.1.0 . Spring security 3.1.0 had a dependency on spring-security-web version 3.0.6 which in turn had a dependency on spring-web 3.0.6. I need to bring it all to 3.1.0. So I exclude spring-security-web from Spring security, have a separate dependency for spring-security-web 3.1.0 which in turn excludes the spring-web 3.0.6 version and I provide a separate spring-web 3.1.0 version. This work but I feel there would be a much easier approach. I tried putting an exclusion for spring web under Spring security but it did not work.
You can utilize the dependency management mechanism.
If you create entries in the <dependencyManagement> section of your pom for spring-security-web and spring-web with the desired 3.1.0 version set the managed version of the artifact will override those specified in the transitive dependency tree.
I'm not sure if that really saves you any code, but it is a cleaner solution IMO.
Global exclusions look like they're being worked on, but until then...
From the Sonatype maven reference (bottom of the page):
Dependency management in a top-level POM is different from just
defining a dependency on a widely shared parent POM. For starters, all
dependencies are inherited. If mysql-connector-java were listed as a
dependency of the top-level parent project, every single project in
the hierarchy would have a reference to this dependency. Instead of
adding in unnecessary dependencies, using dependencyManagement allows
you to consolidate and centralize the management of dependency
versions without adding dependencies which are inherited by all
children. In other words, the dependencyManagement element is
equivalent to an environment variable which allows you to declare a
dependency anywhere below a project without specifying a version
number.
As an example:
<dependencies>
<dependency>
<groupId>commons-httpclient</groupId>
<artifactId>commons-httpclient</artifactId>
<version>3.1</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>3.0.5.RELEASE</version>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>commons-httpclient</groupId>
<artifactId>commons-httpclient</artifactId>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</dependencyManagement>
It doesn't make the code less verbose overall, but it does make it less verbose where it counts. If you still want it less verbose you can follow these tips also from the Sonatype reference.
Related
The dependencies of Spring-web.jar do not contain third-party dependencies now. It only has other jar of spring framework. For example it depends on spring-core.jar. But the spring-web depends on some third-party jars. httpclient.jar is one of them. When I use maven to package my project that depends on spring-web, the httpclient.jar is not download automatically.
this is a segement of spring-web-5.2.15.RELEASE.pom.
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>5.2.15.RELEASE</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>5.2.15.RELEASE</version>
<scope>compile</scope>
</dependency>
</dependencies>
I read the pom of spring-web in early version. I find that the denpendencies include httpclient.jar. But it is disappear in new version now. this is a segment of spring-web-5.1.8.RELEASE.pom.
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.5.9</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<artifactId>commons-logging</artifactId>
<groupId>commons-logging</groupId>
</exclusion>
</exclusions>
<optional>true</optional>
</dependency>
How can I download the dependencies?
i tried adding maven dependency directly, say spring context 3.0.7.release
and tried adding spring-context 3.2.8.release(this has also spring context as transitive depedency), how to exclude spring context 3.0.7. is it to comment or to remove or can we use exclusion here?
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${spring-version} </version>
<!-- <exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-expression</artifactId>
</exclusion>
</exclusions> -->
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-expression</artifactId>
<version>3.0.7.RELEASE</version>
</dependency>
</dependencies>
No need for an exclusion here, the version of spring-expression you have in your own POM overwrites the other version, and Maven takes care that only one version is used.
What is the difference between the way I declare the two dependency?
My project is a spring boot project...
This one I downloaded from Spring Initializer:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-ldap</artifactId>
</dependency>
This one is from mvnrepository.com:
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-ldap</artifactId>
<version>3.1.0.RELEASE</version>
</dependency>
Update, this article shows a third way:
<dependency>
<groupId>org.springframework.ldap</groupId>
<artifactId>spring-ldap-core</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-ldap</artifactId>
</dependency>
The first one is a Spring Boot starter. According to the documentation:
Starters are a set of convenient dependency descriptors that you can include in your application. You get a one-stop shop for all the Spring and related technologies that you need without having to hunt through sample code and copy-paste loads of dependency descriptors.
The pom.xml of spring-boot-starter-data-ldap contains the following dependency definitions:
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-ldap</artifactId>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
The second one: spring-security-ldap is the artifact present in maven central, corresponding to the Spring LDAP project.
activemq not compatibale with spring 4.3.6. And i cant change spring version. I use following dependencies in pom.xml
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jms</artifactId>
<version>4.3.6.RELEASE</version>
<exclusions>
<exclusion>
<artifactId>commons-logging</artifactId>
<groupId>commons-logging</groupId>
</exclusion>
</exclusions>
</dependency>
<!-- ActiveMQ -->
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-all</artifactId>
<version>5.15.0</version>
</dependency>
Where activemq show dependency on 4.3.9 i also tried 5.14.4 which have dependency on 4.1.9.
How can i resolve this issue.
I used client dependency only and now its working.
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-client</artifactId>
<version>5.15.0</version>
</dependency>
This does not have spring dependencies. Either we can use exclusion if we are using all jar or can use specific dependencies needed for project. Thanks for help.
In a Maven project we used a third-party artifact (specifically, spring-data-jpa 1.1.0.RELEASE) which depends on another artifact (spring-core) allowing any version in a range (to be precise: [3.0.7.RELEASE,4.0.0.RELEASE), see its pom-file). We had no direct dependency on spring-core.
So one day our build chose 3.1.2.RELEASE, but when 3.2.0.RC1 was released then our build suddenly picked up that version.
However, we would like to have repeatable builds: when we deliver a patch in a year's time, we don't want to pull in an updated version of spring-core, or any other indirect dependency, without at least knowing about it.
(I know that we can guide Maven to choose one specific version for spring-core, e.g., using <dependencyManagement>, but my point here is that there may be arbitrary choices hidden in indirect dependencies, and I'd like Maven to tell us about those, without having to manually check this regularly.)
Question: How can we make Maven warn us if it makes an arbitrary version choice for any indirect dependency?
As you have discovered, version ranges are evil.
The real issue is that version ranges are a siren that seduces people into thinking they are a good idea.
A version range should really be seen as a hint to the developer to allow the developer to choose the version they want from a set of versions.
The mistake in Maven was in allowing version ranges to be defined within the pom.xml in the first place as that allows for people to publish their artifacts with version ranges in them.
Once you have a dependency on an artifact which has transitive dependencies that use version ranges, there are really only two ways to solve the problem for your build (and one is just a more fancy version of the second)
Add your own dependency on the transitive dependency but with a pinned version in place of a range... e.g.
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
<version>1.1.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-orm</artifactId>
<version>3.1.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-tx</artifactId>
<version>3.1.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>3.1.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>3.1.2.RELEASE</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
You don't need to list <optional>true</optional> dependencies as they are not transitive and similarly you don't need to list <scope>provided</scope> dependencies either for the same reason.
As for the above, but being safer by adding exclusions to the dependency in the first place, e.g.
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
<version>1.1.0.RELEASE</version>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-orm</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-tx</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-orm</artifactId>
<version>3.1.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-tx</artifactId>
<version>3.1.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>3.1.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>3.1.2.RELEASE</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
Of the two of these, I prefer the latter as it at least gives people a hint as to why those dependencies are being explicitly mentioned.
So to get back to your original question, the point is that you need to set up this dependency tree when you add or update dependencies in your pom.xml.
If spring-data-jpa:1.1.1.RELEASE had a completely different transitive dependency tree with different coordinates, it is when you are editing the pom.xml to update the version that you should also fix the transitives.
There is not, to my knowledge, currently any enforcer rules to support validating what you require.
I would recommend writing an enforcer rule which I would call something like: ensureTransitiveVersionRangesArePinned
That rule should do the following:
Scan the list of project dependencies
Compute the transitive dependencies provided by each project dependency
If any of those transitive dependencies are version ranges then
validate that there is an exclusion for that transitive dependency
validate that there is a pinned version of the transitive dependency as a direct project dependency (may not be a failure if there is no pinned version, as you may be adding an equivalent artifact that is at a different GAV, or you may not need the dependency)... in any case if the dependency is not added back in, most likely the unit tests should catch that by triggering a CNFE so this check is probably not strictly required, but it should perhaps print a warning.
I cannot recall if there is tooling to check that the <exclusions> are actually excluding any transitive dependencies, so you may need to investigate that.