I have developed a Java library using the java-library Gradle plugin. This library has e dependency on protobuf-java which I need to expose as a transitive dependency to users of the library.
I have the following snippets in my library's build.gradle
plugins {
id 'java-library'
id "maven-publish"
id "com.google.protobuf" version "0.8.16"
}
...
dependencies {
api ("com.google.protobuf:protobuf-java:3.17.3")
testImplementation("com.google.protobuf:protobuf-java-util:3.17.3")
testImplementation("org.junit.jupiter:junit-jupiter-api:5.7.2")
testImplementation("org.junit.jupiter:junit-jupiter-engine:5.7.2")
}
Running gradlew dependencies gives me the following as expected
api - API dependencies for source set 'main'. (n)
\--- com.google.protobuf:protobuf-java:3.17.3 (n)
But when I add the library as a dependency to in my main app, I don't get any transitive dependencies. Doing a gradlew dependencies in my main app gives me:
compileClasspath - Compile classpath for source set 'main'.
+--- my-library:my-library:1.0.21
+--- javax.jms:javax.jms-api -> 2.0.1
....
What could be the cause for the dependency not showing up in the main app?
The problem was with the maven-publish plugin.
I had to add the following to my publishing section to get it to work.
publications {
mavenJava(MavenPublication) { from project.components.java }
}
Related
Use Case
I am trying to generate a dependency tree containing all plugins and dependencies for all configurations, but org.sonarqube is not included in the tree. I am working with a basic, single-module project and am using Gradle v7.5.1.
Examples
Running the following command outputs most (but not all) dependencies and plugins.
gradlew dependencies > dependency-tree.txt
Specify SonarQube plugin within build.gradle
plugins {
id 'org.sonarqube' version '3.2.0'
}
Specify SonarQube plugin within settings.gradle
buildscript {
repositories {
maven {
url "https://plugins.gradle.org/m2/"
}
}
dependencies {
classpath "org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:3.2.0"
}
}
apply plugin: "org.sonarqube" // set in build.gradle, not in settings.gradle
Results
Neither approach includes the org.sonarqube plugin in the dependency graph. Is there a way to get this plugin to show up in the generated dependency tree? If yes, what changes need to be made?
The dependencies task provides the projet dependencies in each configuration, this does not include the projet script classpath (plugins).
You have another similar task available, buildEnvironment (see BuildEnvironmentReportTask) which will list the project build script dependencies.
you could combine both tasks outputs if you need a aggredated report of all project/plugin dependencies
> Task :buildEnvironment
------------------------------------------------------------
Root project 'demo'
------------------------------------------------------------
classpath
\--- org.sonarqube:org.sonarqube.gradle.plugin:3.2.0
\--- org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:3.2.0
\--- org.sonarsource.scanner.api:sonar-scanner-api:2.16.1.361
A web-based, searchable dependency report is available by adding the --scan option.
BUILD SUCCESSFUL in 452ms
I have a multi-module Gradle 6.5 project which also includes some test fixtures code. To avoid dependency issues I'd like to set (and maintain) the versions in one place, and just refer to the version-less dependencies in the individual modules:
subprojects {
apply plugin: 'java'
dependencies {
implementation 'com.google.guava:guava'
constraints {
implementation 'com.google.guava:guava:20.0'
compileOnly 'com.google.code.findbugs:jsr305:3.0.2'
}
}
}
Now, if a module includes compilyOnly 'com.google.code.findbugs:jsr305' the version 3.0.2 is taken based on the constraints above. This works fine if I know the configuration (implementation, compileOnly, ...).
The question now is: How can I specify versions that apply to all configuration? What if a module decides to use JSR305 annotations for test fixtures code? testFixtures 'com.google.code.findbugs:jsr305' fails, as the version is not specified anywhere. I also think it's a bad idea to repeat the version specification for all (possible) configuration:
implementation 'com.google.code.findbugs:jsr305:3.0.2'
testFixturesImplementation 'com.google.code.findbugs:jsr305:3.0.2'
compileOnly 'com.google.code.findbugs:jsr305:3.0.2'
Is there a shortcut to this?
If fixed this using the java-platform plugin.
Platform:
plugins {
id 'java-platform'
}
dependencies {
constraints {
api 'com.google.guava:guava:20.0'
api 'com.google.code.findbugs:jsr305:3.0.2'
}
}
Regular module with test fixtures:
plugins {
id "java-test-fixtures"
}
dependencies {
testFixturesImplementation platform(project(':platform-module'))
testFixturesCompileOnly 'com.google.code.findbugs:jsr305'
}
./gradlew -q module-with-test-fixtures:dependencies gives:
[...]
testFixturesCompileClasspath - Compile classpath for source set 'test fixtures'.
+--- project :module-with-test-fixtures (*)
+--- com.google.code.findbugs:jsr305 -> 3.0.2
\--- project :platform-module
\--- com.google.code.findbugs:jsr305:3.0.2 (c)
[...]
(c) - dependency constraint
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
Why is Gradle changing my library's transitive dependency to a newer version? How do I get it to stop?
Details
I am working on an internal plugin library for my company that uses Spring Security. The plugin explicitly declares a dependency on the latest version of Spring Security 4:
compile ('org.springframework.security:spring-security-core:4.2.13.RELEASE') {
force = true
}
When I include the plugin in a client project, Gradle is upgrading me from spring security 4 to 5, which breaks the plugin.
compile 'com.mycompany:my-security-plugin:0.3.0-SNAPSHOT'
Here is the output from dependencyInsight in the client project:
> Task :dependencyInsight
org.springframework.security:spring-security-core:5.1.6.RELEASE (selected by rule)
variant "compile" [
org.gradle.status = release (not requested)
org.gradle.usage = java-api
org.gradle.component.category = library (not requested)
]
org.springframework.security:spring-security-core:5.1.6.RELEASE
+--- org.springframework.security:spring-security-config:5.1.6.RELEASE
| \--- com.mycompany:my-security-plugin:0.3.0-SNAPSHOT:20200122.162056-4 (requested org.springframework.security:spring-security-config:4.2.13.RELEASE)
| \--- compileClasspath
\--- org.springframework.security:spring-security-web:5.1.6.RELEASE
\--- com.mycompany:my-security-plugin:0.3.0-SNAPSHOT:20200122.162056-4 (requested org.springframework.security:spring-security-web:4.2.13.RELEASE) (*)
org.springframework.security:spring-security-core:4.2.13.RELEASE -> 5.1.6.RELEASE
\--- com.mycompany:my-security-plugin:0.3.0-SNAPSHOT:20200122.162056-4
\--- compileClasspath
It looks to me like in all cases, I am requesting spring security 4 in my config. What am I doing wrong?
I am using Gradle 5.1.1.
Update
As a workaround, it is possible to have the client app declare a direct dependency on spring security, using a specific version. I'm trying to avoid this, if possible.
Update 2
Output from gradlew dependencyInsight --dependency org.springframework.security:spring-security-web:
> Task :dependencyInsight
org.springframework.security:spring-security-web:5.1.6.RELEASE (selected by rule)
variant "compile" [
org.gradle.status = release (not requested)
org.gradle.usage = java-api
org.gradle.component.category = library (not requested)
]
org.springframework.security:spring-security-web:4.2.13.RELEASE -> 5.1.6.RELEASE
\--- com.mycompany:my-security-plugin:0.3.0-SNAPSHOT:20200122.162056-4
\--- compileClasspath
Update 3
The buildEnvironment includes the following, via grails:
+--- org.springframework.boot:spring-boot-gradle-plugin:2.1.9.RELEASE
| | +--- org.springframework.boot:spring-boot-loader-tools:2.1.9.RELEASE (*)
| | +--- io.spring.gradle:dependency-management-plugin:1.0.8.RELEASE
Am I correct in assuming that you use the Spring Dependency Management Plugin (io.spring.dependency-management) and maybe also the Spring Boot Gradle Plugin (org.springframework.boot)? Then it’s very likely that this combination will also manage the eventual version of spring-security-core for you, irrespective of what other pieces of your build setup request.
Minimal Setup Demonstrating the Problem
I have the following two Gradle builds sitting next to each other (omitting the Gradle 5.1.1 Wrapper files for brevity):
my-security-plugin
└── build.gradle
my-client
├── build.gradle
└── settings.gradle
Running the following Gradle command from within my-client gives me (roughly) the same output as in the OP’s question:
./gradlew dependencyInsight --configuration compile --dependency org.springframework.security:spring-security-core
my-security-plugin/build.gradle
plugins {
id 'java'
}
group = 'com.mycompany'
version = '0.3.0-SNAPSHOT'
repositories {
jcenter()
}
dependencies {
compile ('org.springframework.security:spring-security-core:4.2.13.RELEASE') {
force = true
}
compile 'org.springframework.security:spring-security-config:4.2.13.RELEASE'
compile 'org.springframework.security:spring-security-web:4.2.13.RELEASE'
}
my-client/build.gradle
plugins {
id 'java'
id 'org.springframework.boot' version '2.1.7.RELEASE'
id 'io.spring.dependency-management' version '1.0.9.RELEASE'
}
group = 'com.mycompany'
version = '1.0.0'
repositories {
jcenter()
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-security'
compile 'com.mycompany:my-security-plugin:0.3.0-SNAPSHOT'
}
my-client/settings.gradle
includeBuild '../my-security-plugin'
This file is only here to define a Gradle composite build; includeBuild won’t be there in the production build, you will rather publish the my-security-plugin to some repository from where my-client downloads it.
Possible Solutions to the Problem
As mentioned in the introduction, the combination of Spring Dependency Management Plugin and Spring Boot Gradle Plugin defines the version of spring-security-core for your build. Aside from your own workaround, there are three possibilities to get to the version you want:
Use the Spring Boot version that selects the same version of spring-security-core that you need: id 'org.springframework.boot' version '1.5.22.RELEASE'
Customize the managed versions by setting an extra property in your build: ext['spring-security.version'] = '4.2.13.RELEASE'
Don’t let Spring manage your dependencies at all …
All these solutions obviously have drawbacks:
solution 1 forces you to use an old Spring Boot version
solution 2 forces you to request the required version of a transitive dependency in your client app (which is similar to your own workaround that you wanted to avoid)
solution 3 may not be worth the extra work that manually managing all Spring dependencies would incur
Now you only have to choose the lesser evil ;-)
The java-library plugin documentation says:
Dependencies appearing in the api configurations will be transitively exposed to consumers of the library, and as such will appear on the compile classpath of consumers.
Dependencies found in the implementation configuration will, on the other hand, not be exposed to consumers, and therefore not leak into the consumers' compile classpath
However, it doesn't work for me. I see that the implementation dependencies are exposed to consumers too.
Here one example:
project_a -> build.gradle
...
dependencies {
// Dependency supposedly not exposed to consumers in their own classpath compilation
implementation 'com.google.guava:guava:23.0'
}
...
project_b -> build.gradle
...
dependencies {
implementation 'my-company:project_a:1.0'
}
...
I expected that guava doesn't appear in the project_b' classpath. However I see guava and all their dependencies on the project_b compile classpath.
project_b>> gradlew dependencies:
...
compileClasspath - Compile classpath for source set 'main'.
\--- my-company:project_a:1.0
\--- com.google.guava:guava:23.0
+--- com.google.code.findbugs:jsr305:1.3.9
+--- com.google.errorprone:error_prone_annotations:2.0.18
+--- com.google.j2objc:j2objc-annotations:1.1
\--- org.codehaus.mojo:animal-sniffer-annotations:1.14
...
The reason you do not experience this behaviour is because your dependency goes through a Maven POM.
The separation of the Maven compile and runtime scopes is only supported as of Gradle 4.6 and is currently behind a feature flag.
In short, if you add the following to settings.gradle of project_b, you will get the expected behaviour:
enableFeaturePreview("IMPROVED_POM_SUPPORT")
I believe the documentation refers to multi-project builds, and that a consumer is considered to be a project (not a jar) that depends on another project in the build.
For example, consider this project_b/build.gradle:
dependencies {
implementation project(':project_a')
}
With this (and the appropriate settings.gradle), I can observe the compile classpath changes as the doc describes (for use of api versus implementation). I have placed a working example here.