When executing (in gradle 6.5)
./gradlew dependencyInsight --dependency groovy-testng --configuration testRuntimeClasspath
I could find groovy-testng comes from groovy-all library which was added to our build.gradle. I wanted to update version of groovy-testng, so I decided to update groovy-all which, according to mvnrepository, contains groovy-testng in version 3.0.4, but still the version of groovy-testng was the old one and gradle didn't resolve it to the latest version:
org.codehaus.groovy:groovy-testng:2.5.12 (selected by rule)
variant "runtime" [
org.gradle.status = release (not requested)
org.gradle.usage = java-runtime
org.gradle.libraryelements = jar
org.gradle.category = library
Requested attributes not found in the selected variant:
org.gradle.dependency.bundling = external
org.gradle.jvm.version = 11
]
org.codehaus.groovy:groovy-testng:3.0.4 -> 2.5.12
\--- org.codehaus.groovy:groovy-all:3.0.4
\--- testRuntimeClasspath
I have found the line selected by rule but couldn't find any ResolutionStrategy in my project, so I started to comment out and see what causes this. It turned out it's a plugin org.springframework.boot together with io.spring.dependency-management causes this version to be downgraded. Why? And why only when both of them are included? I assume these plugins define some ResolutionStrategy? What is the easiest way to find out where is the ResolutionStrategy coming from?
The Spring Dependency Management plugin is rather heavy handed. If were you build your project with --info or -i, you will see a bunch of these logs:
Applying dependency management to configuration 'bootArchives' in project 'demo'
Applying dependency management to configuration 'archives' in project 'demo'
Applying dependency management to configuration 'default' in project 'demo'
Applying dependency management to configuration 'compile' in project 'demo'
Applying dependency management to configuration 'implementation' in project 'demo'
Applying dependency management to configuration 'runtime' in project 'demo'
Applying dependency management to configuration 'compileOnly' in project 'demo'
From my experience, the dependency management plugin will win/force itself to win.
I can see in your snippet, that you wanted 3.0.4 of Groovy, but Gradle resolved 2.5.12. If you look at the Spring Boot Dependencies BOM, you will see that 2.5.12 is the current version for Spring Boot 2.3.1: https://github.com/spring-projects/spring-boot/blob/2.3.x/spring-boot-project/spring-boot-dependencies/build.gradle#L365..L371
The Spring Boot Gradle plugin detects if the Spring dependency management plugin is present, and if so, configures the plugin to import the Spring Boot dependencies BOM: https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/main/java/org/springframework/boot/gradle/plugin/DependencyManagementPluginAction.java
From looking at the BOM: https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-dependencies/2.3.1.RELEASE/spring-boot-dependencies-2.3.1.RELEASE.pom
You should be able to override the Groovy version like so:
ext {
set("groovy.version", "3.0.4")
}
The Spring dependency management plugin should pick that up and apply 3.0.4
If that doesn't solve your issue, then you have other plugins or configuration at play here that you will need to figure out.
I also suggest watching Managing Dependencies for Spring Projects with Gradle to learn the differences between Spring dependency management plugin and Gradle's native dependency management.
Related
My goal is to produce an artifact of my Spring Boot application that I can use as a dependency and [edit] that is a fat jar, that is, it contains all the dependencies of my application [edit].
I use gradle as a build tool with the following plugins:
plugins {
id 'java'
id 'org.springframework.boot' version '2.7.4'
id 'io.spring.dependency-management' version '1.0.14.RELEASE'
id 'org.jetbrains.gradle.plugin.idea-ext' version '1.1.6'
}
Now, the Spring Boot documentation states at
https://docs.spring.io/spring-boot/docs/current/reference/html/howto.html#howto.build.use-a-spring-boot-application-as-dependency that
'Spring Boot’s Maven and Gradle plugins must be configured to produce a separate artifact that is suitable for use as a dependency [...] To produce the two artifacts, one that can be used as a dependency and one that is executable, a classifier must be specified. This classifier is applied to the name of the executable archive, leaving the default archive for use as a dependency.'
This is followed by a description on how to do this with the build tool maven, but there is no mentioning of how to do this in gradle.
Any help of how to set this up with gradle is much appreciated.
When building with Gradle, an artifact with a plain classifier is built by default. This artifact is a standard, plain jar file that is suitable for use as a dependency.
I am using Gradle 6.1 in a multimodule project. I am also using two plugins: kotlin("jvm") and id("com.google.cloud.tools.jib"), and they are loaded in the following modules:
root/
build.gradle.kts loads kotlin("jvm")
services/
my-service/
rest/
build.gradle.kts loads id("com.google.cloud.tools.jib")
(There are more modules, files etc. but these are the relevant ones.)
The build fails:
$ ./gradlew clean jibDockerBuild
...
* What went wrong:
Execution failed for task ':services:driver:rest:jibDockerBuild'.
> com.google.cloud.tools.jib.plugins.common.BuildStepsExecutionException: 'org.apache.http.client.config.RequestConfig$Builder
org.apache.http.client.config.RequestConfig$Builder.setNormalizeUri(boolean)'
I identified the issue: both the Kotlin and JIB plugins have a transitive dependency on org.apache.httpcomponents:httpclient: Kotlin requires 4.5.3 and JIB 4.5.10. The problem is, in this project setup only 4.5.3 is loaded, and JIB fails as the new method is not available. This can be checked with ./gradlew buildEnv.
I've found a workaround, I need to load both plugins at the root level (which one is first seems to be irrelevant) in the main Gradle file; now ./gradlew buildEnv shows that the higher dependency version is used, also for Kotlin (output shortened and incomplete):
classpath
+--- org.jetbrains.kotlin.jvm:org.jetbrains.kotlin.jvm.gradle.plugin:1.3.61
| \--- org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.61
| +--- de.undercouch:gradle-download-task:3.4.3
| | \--- org.apache.httpcomponents:httpclient:4.5.3 -> 4.5.10
It works in this case, but it could be that the new library version breaks the Kotlin plugin. The problem is that the plugins and their dependencies are on the classpath without separation, something that was normal on Java before Jigsaw etc. Is there any way for Gradle to be able to separate the dependencies so that each plugin uses exactly the version it declares? I am building on Java 11, so the module system could be utilized, but does Gradle have an option to turn it on?
EDIT: updating to Kotlin 1.3.70 also fixes the issue as it doesn't depend on the library any longer. The general question is still valid, though.
Is there any way for Gradle to be able to separate the dependencies so that each plugin uses exactly the version it declares
No.
All plugins share the same build script configuration: classpath
It follows the same dependency resolution that application dependencies follow. So you can enforce that for this particular dependency only use a specific version always:
buildscript {
configurations {
classpath {
resolutionStrategy {
force("org.apache.httpcomponents:httpclient:4.5.10")
}
}
}
}
That's just one of many ways you can take control of dependency resolution for build script dependencies. You could also use a platform to advise on the dependency versions:
buildscript {
dependencies {
classpath(enforcedPlatform("org.springframework.boot:spring-boot-dependencies:2.2.5.RELEASE"))
}
}
Refer to the docs for more info:
https://docs.gradle.org/current/userguide/resolution_rules.html
https://docs.gradle.org/current/userguide/platforms.html
I got gradle 3.5.1 and using ear plugin. The documentation says that deploy configuration is not transitive but earlib actually is (https://docs.gradle.org/3.3/userguide/ear_plugin.html). My configuration is a below
dependencies {
earlib(
"org.mybatis:mybatis:3.2.8"
)
}
It was supposed to get a few other transitive libraries but here is all I get when I run gradle dependencies
earlib - Classpath for module dependencies.
\--- org.mybatis:mybatis:3.2.8
What am I doing wrong here?
Actually, you are doing nothing wrong. Your module dependency org.mybatis:mybatis:3.2.8 simply does not define any (mandatory) transitive dependency, since every compile or provided dependency is marked as optional.
According to the Maven docs,
If a user wants to use functionality related to an optional dependency, they will have to redeclare that optional dependency in their own project.
I use gradle with the new java-library plugin.
With this plugin we can use new configurations for dependencies instead of 'compile', 'runtime', 'test' etc.
see java-library plugin documentation
But with the spring-boot plugin, when I launch the task
gradle build
The produced jar does not contain the dependencies of the project.
It is because I use the 'implementation' configuration.
If I use 'compile' configuration as I did before, it works.
Is there a solution, to use these new configurations ?
Or do you plan to implement this new feature in the next versions of spring-boot.
Thank you :)
I'm using mongodb with Spring Boot. Recently, my mongodb was upgraded to version 3.0.
I'm using the following Gradle dependencies for Spring:
buildscript {
ext {
springBootVersion = '1.2.6.RELEASE'
}
dependencies {
compile 'org.springframework.boot:spring-boot-starter-data-mongodb'
}
If I look on maven repositories for Gradle: 'org.springframework.boot:spring-boot-starter-data-mongodb:1.2.6.RELEASE', I see the following (http://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-data-mongodb/1.2.6.RELEASE):
The dependencies for the mongo-java-drivers are 2.12.5 under the "Version" column. I was wondering what the "Update" column is there for and how can I use the version of the mongo-java-drivers listed there instead (3.0.4)?
Since I'm using mongo 3.0, I would like to use the 3.0.4 java-drivers instead of 2.12.5 as I need to update my java-drivers to be at least 2.13 before they will work with my mongodb 3.0: http://docs.mongodb.org/manual/release-notes/3.0-scram/#upgrade-drivers
Just add the following dependency to your project dependencies:
compile 'org.mongodb:mongo-java-driver:3.0.4'
This will explicitly set there mongodb Java driver to the newest version and will overrun the transitive dependency version of spring-boot-starter-data-mongodb.
BTW, the "Updates" column means the newest version for a specific Artifact.
You can force the usage of a newer version of a dependency by just explicitly adding the dependency version that you want to use in the pom.xml.
Then Maven will use the explicitly specified version to compile.
FYI, you can exclude a dependency triggered by a direct dependency by using the exclude element.
See this doc to know how maven manages dependencies.
If you are using Gradle, see this page. In fact, you exclude the MongoDB transitive dependency triggered by spring boot and you explicitly add the latest version as a direct dependency.