Situation: In my build.gradle file I have 2 separate configurations for pulling in specific dependencies.
One is called configJars where I pull down jars to unpack and get specific json files from.
My question is, is there a way to call out the versions that are already being resolved in the compile/transitive dependencies.
com.example:common:2.0.0-SNAPSHOT -> 2.0.1-SNAPSHOT
I attempted to use "+" but this only pulls the latest version that is available in the repo which is not what I require.
configJars(group: "com.example", name: "common", version: "+")
+--- com.example:common:+ -> 3.2.18-SNAPSHOT
I need to use the version that is being used by a specific dependency that gets updated by a different team.
I ended up adding the library that was doing the update to my other libraries and removed the other libraries from the build file. SO they get pulled in transitively and explicitly exclude the libraries I don't need from the transitive pull.
I had to change the configuration to transitive = true and change all the dependency declarations to { transitive = false}.
A bit messy but it worked out.
I have a multi-module gradle project where in a module I add dependencies in compile configuration on runtime.
Those dependencies fetch a transitive dependency with a version prefix that does not exist.
So case is like this
compile 'group:moduleA:version.+'
This moduleA downloads moduleB with same version.+ prefix notation and that downloads another moduleC with same prefix notation, moduleC is present in artifactory with version 10 and above and 8 and below, so there are no versions which are number 9, and gradle insist on finding moduleC with version 9, it doesn't fetch versions above or below it.
How can I make gradle fetch another version if the version its trying to find is not there?
Please comment for any clarification and thanks for helping.
EDIT: Want to clarify that + in version part is not resolving to a number which is correct and present on artifactory, like 9.1 or 9.12.
gradle determines this version, which is incorrect like 9.1 is present but it resolves to 9.2 or some other number which is not there.
EDIT2: Task which is used to fetch dependencies and then add them in compile configuration.
task addAdditionalDependencies {
doLast {
Object slurper = new JsonSlurper().parseText(api.jsonResponse())
Set<String> dependencyNames = configurations.compile.dependencies.collect { it.name }
List<Map<String, String>> artifactPaths = slurper.results.collect {
String[] pathSegments = it.path.split('/')
if (!dependencyNames.contains(pathSegments[1]) && project.name != pathSegments[1]) {
[group: pathSegments[0],
name: pathSegments[1],
version: "version.+",
configuration: 'compile']
} else [:]
}
artifactPaths.each {
if (!it.isEmpty()) {
project.dependencies.add('compile', it)
}
}
// we have to call this because app does not have any source files and so compileJava does not download
// dependencies
configurations.compile.files
}
}
When using a version like 9.+, Gradle will looks for all version that matches the prefix, that is the part before the +.
There is however no way to make Gradle ignore that part in case no such version exist.
If the version of moduleC can be anything, then you could simply use + without any prefix.
Note that doing something like that could expose you to breakage in a build even though nothing changed, aside from a new version of moduleC being published.
You could also combine this dynamic version resolution with dependency locking to have a finer grained control on when to upgrade moduleC.
One of my build scripts imports that nebula plugin:
plugins {
id 'nebula.ospackage' version '3.5.0'
}
I've been moving all of my version info into a separate file that all projects have access to and am wondering what is the correct syntax to convert to something like:
plugins {
id 'nebula.ospackage' version "$versions.nebula_gradle_ospackage_plugin"
}
When I try running the above with "gradle clean build", I get the following error:
build file 'build.gradle': 2: argument list must be exactly 1 literal
non empty string
See
https://docs.gradle.org/2.7/userguide/plugins.html#sec:plugins_block
for information on the plugins {} block
# line 2, column 33.
id 'nebula.ospackage' version "$versions.nebula_gradle_ospackage_plugin"
The linked article shows how I could use the "buildscript" block, which works, but it seems like there must be a way to make this work in a single line?
As of Gradle 5.6, you can declare your plugin versions in the gradle.properties file, and reference these properties in plugins block.
For example, the gradle.properties file:
springBootVersion=2.2.0.RELEASE
the plugins block in build.gradle:
plugins {
id "org.springframework.boot" version "${springBootVersion}"
}
See: https://github.com/gradle/gradle/issues/1697#issuecomment-506910915.
See also:
https://docs.gradle.org/5.6/release-notes.html#central-management-of-plugin-versions-with-settings-script
https://docs.gradle.org/5.6/userguide/plugins.html#sec:plugin_management
You cannot use variable here:
Where «plugin version» and «plugin id» must be constant, literal,
strings. No other statements are allowed; their presence will cause a
compilation error.
This is an old post, but the bug is still open, and I found this post looking for workarounds.
It seems you were aware of this already, and actually have BoygeniusDexter's answer, but I think this may help others finding this post like I did. The following workaround is based on the Gradle docs and solved the problem for me:
buildscript {
ext {
springBootVersion = '2.0.4.RELEASE'
}
repositories {
mavenCentral()
}
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
}
}
plugins {
id 'java'
// and other plugins
id 'io.spring.dependency-management' version '1.0.6.RELEASE'
}
// but the one with the variable version is applied the old way:
apply plugin: 'org.springframework.boot'
// We can use the variable in dependencies, too:
dependencies {
compile group: 'org.springframework.boot', name: 'spring-boot-starter-web', version: springBootVersion
// ...
}
In addition to #zhouji comment, you can not only specify the versions in gradle.properties, but you can also define it programmatically like:
buildscript {
ext {
kotlinVersion = "${JavaVersion.current().isCompatibleWith(JavaVersion.VERSION_16) ? '1.5.32' : '1.4.32'}"
}
}
plugins {
id 'org.jetbrains.kotlin.jvm' version "${kotlinVersion}"
}
Gradle 7
Gradle 7 introduced version catalogs for declaring dependencies and sharing them between projects/modules.
Plugins can be declared in the catalog:
// settings.gradle
dependencyResolutionManagement {
versionCatalogs {
libs {
version('android-plugins', '7.3.0')
plugin('android-application', 'com.android.application').versionRef('android-plugins')
// A library declaration using the same version.
library('some-library', 'com.group', 'artifact').versionRef('android-plugins')
}
}
}
The declaration can be referred to in the plugins block:
// build.gradle
plugins {
alias(libs.plugins.android.application) apply false
}
The version can also be referred to in the plugins block:
// build.gradle
plugins {
id 'com.android.application' version libs.versions.android.plugins apply false
}
See the version catalogs documentation for more information.
Note: In the declaration, - is used as separator in the dependency name. On the consuming side . is used instead, as - is the sign for the minus operator of the groovy language and can't be used in property names.
So the separators are different on the declaring and consuming side - which threw me off at first.
Summary
Omit the version from the plugin block
Move/specify the version in the buildscript.dependencies block, instead
Use a variable in that block that is a const variable
In short, plugin blocks require string literals or properties whereas dependency blocks permit varables. The original question asks for doing this in a "single line" and with this approach, your plugin block is shorter and all your dependencies live in one place for all modules. Depending on your goals, that might be better than doing everything in "one line."
Full Example
For Android, I was able to do this by omitting the version from the plugin block and then specifying it as a const in the buildscript dependencies, instead. That block allows variables, whereas the plugin block only allows string literals. From there, I use an object in buildSrc because that provides the most flexibility, while keeping all dependency info in one file for all modules. So my setup looks like this:
├── project/
│ ├── build.gradle
| └── app/
| └── build.gradle
| └── buildSrc/
| └── build.gradle.kts
| └── src/main/java/com/example/package/Deps.kt
From there, to specify any plugin version as a variable in one place, the app/build.gradle file omits the version (using kotlin as an example but the same approach works for any plugin):
app/build.gradle
plugins {
id 'kotlin-android' // omit version property here but provide it in buildscript dependencies
...
}
...
dependencies {
...
// Dagger
implementation Deps.Dagger.ANDROID_SUPPORT
kapt Deps.Dagger.ANDROID_PROCESSOR
kapt Deps.Dagger.COMPILER
}
Then the buildscript dependency section (usually in the parent build.gradle file but can also be in the same file) provides the version USING A VARIABLE!
project/build.gradle
import com.example.package.Deps // object in the buildSrc folder with all version info
buildscript {
dependencies {
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:${Deps.kotlinVersion}"
}
}
Lastly, all the version information is managed in buildSrc, with an object in the Deps.kt file (there are many blog posts out there on using buildSrc with Android projects):
Deps.kt
object Deps {
// For use in the top-level buildscript dependency section which only works with a constant rather than `Deps.Kotlin.version`
const val kotlinVersion = "1.3.72"
object Kotlin : Version(kotlinVersion) {
val STDLIB = "org.jetbrains.kotlin:kotlin-stdlib-jdk8:$version"
}
object Dagger : Version("2.25.2") {
val ANDROID_SUPPORT = "com.google.dagger:dagger-android-support:$version"
val ANDROID_PROCESSOR = "com.google.dagger:dagger-android-processor:$version"
val COMPILER = "com.google.dagger:dagger-compiler:$version"
}
}
open class Version(#JvmField val version: String)
Overall, I really like this setup. It's flexible, all dependency info is in one place, even across multiple modules and, best of all, it allows for code completion in the gradle files, when typing dependencies!
// gradle.properties
springBootVersion=2.6.7
// settings.gradle.kts
pluginManagement {
val springBootVersion: String by settings
plugins {
id("org.springframework.boot") version springBootVersion
}
}
// build.gradle.kts
plugins {
id("org.springframework.boot")
}
I hit this issue.
when I ran
gradle clean test build
instead of
./gradlew clean test build
and my "gradle" was at version 4.x
but my ./gradlew resolved to 6.9 or higher.
aka, "oops, I forgot my build.gradle files were coded to use later versions of gradle(w), but I snapfu-ed and executed the older 4.x version of regular "gradle"
This is not a duplicate since those other solutions did not work.
I have a sub-project:
:commons:widget
gradle.build (sub-project) resembles this:
configurations {providedCompile}
dependencies {
compile project(":commons:other-widget")
...other dependencies...
}
If you display the dependencies:
+--- project :commons:some-other-project
+--- project :commons:exclude-me-project (*)
\--- org.apache.cxf:cxf-rt-frontend-jaxrs: -> 3.0.3 (*)
What doesn't work:
Any of the usual syntax. I've tried every variation I can think of. Even went looking for the API but was unable to find what I need there.
In this project's dependencies section:
...
compile project(":commons:some-other-project") {
exclude (":commons:exclude-me-project")
}
Result:
Could not find method exclude() for arguments [:commons:some-other-project] on project
I've also tried:
compile ( project (':commons:some-other-project') ) {
transitive = false
}
Result: Instead of removing dependencies of ":commons:some-other-project", it removes ":commons:some-other-project".
I have a large and complicated project to convert. I've a lot of this sort of work ahead of me. Given a project as a dependency, how do I exclude things from it?
exclude for dependencies has a little bit another syntax, so try to do it providing the module name, which is equals to the exclude-me-project name, like:
compile(project(":commons:some-other-project")) {
exclude module: "exclude-me-project"
}
Alternatively, you may exclude all the transitive dependencies for commons project, but it will remove all the deps of the some-other-project project, including the exclude-me-project:
compile(project(":commons:some-other-project")) {
transitive = false
}
for new gradle syntax you can do something like:
implementation (project(path: ':my_library_v1.0.0')) {
exclude (group: 'com.google.code.gson', module: 'gson')
}
Kotlin DSL answer
This will exclude a subproject from another subproject:
implementation(project(":nice-subproject")) {
exclude(module = "annoying-transitive-subproject")
}
Also note that using exclude on a test fixture dependency requires a cast
implementation(testFixtures(project(":nice-subproject")) as ModuleDependency) {
exclude(module = "annoying-transitive-subproject")
}
is there a way to specify that I want Gradle's conflict resolution to fail on conflict, but only when I did NOT specify some forced modules ?
Let's say groupe:module has a transitive dependency with groupe:module1
example1:
dependencies {
compile 'group:module:version'
compile ('groupe:module1:version1') {
force = true
}
}
In this case, I do NOT want to fail if there is a conflict between dependencies.
(Because I consider that I know what I do when I force module1 to be at version1. I know that other higher dependencies will be taken from version1, even if they conflict with the default version)
example2:
dependencies {
compile 'group:module:version'
}
In this case, if there are some conflicts between second level dependencies, I want to be notified (because this is not supposed to happen in my dependencies trees)
I tried something like :
configurations.all {
resolutionStrategy {
if ( forcedModules.isEmpty() ){
failOnVersionConflict()
}
}
}
but (as I feared) I did not work
As long as you force module versions with resolutionStrategy.force, you'll get this behavior out-of-the-box. If you must force as part of declaring the dependency, you may have to iterate over all of the configuration's ExternalDependencys and check if any of them has force set to true.