Can I configure the variant matching algorithm so that any variant missing a given attribute gets rejected? I’m under the impression that missing attributes are matched by default which creates false positives when using lenient configurations for cross-project aggregations.

Hi. Snyk has revealed that some deeply nested transitive dependencies have CVEs against them. I'd like to specify that gradle choose the greater of the first version without the CVE and whatever version would otherwise be brought in transitively. Is that possible?

Hello Team. one of the tools I work with (Palantir foundry) uses gradle and conda for managing python package dependencies. And it seems that I am running around in circles. What are it's best practices and also, how do I enable verbose logging?

How do I get the task dependencies necessary for a

ResolvableArtifact

? As

ResolvableArtifact

already is internal, it would be ok to use internal stuff for this specific need I have right now. In the end it will anyway land in a PR for Gradle code.

In a configuration, I have a dependency on a JVM library. However, this library is actually published by another project in the same build. e.g.

./gradlew :foo:dependencies --configuration barClasspath

baz:bar:1.0.0

and there is a project in the same build called

bar

in the group

baz

. I would like to substitute the dependency with the project, so it always uses the most recent code, without splitting this into multiple builds. Is it possible?

is it possible with component metadata to add a dependency before another dependency? I want to add the platform jakarta bom before spring boot dependencies (bom) dynamically. Spring boot dependencies would override some of its versions, but doesn't provide all of the same versions. So I can't simply add (append) the dependency since it needs to be applied in a certain order. I suppose spring boot would treat this as an import

I need some help on the basics of dependency substitution. Currently, I have a project that does this:

configurations.all {
  resolutionStrategy.dependencySubstitution {
    substitute(module("foo:bar")).using(module("foo:baz:1.0"))
  }
}

How is this different from

dependencies {
  modules {
    module("foo:bar") {
      replacedBy("foo:baz")
    }
  }
}

and which one is preferred?

hello, I'm writing a plugin to build, expose and consume python packages. I'm modeling this using variant-aware resolution: specifically, I want to expose an artifact with a specific usage attribute, and have a corresponding resolvable configuration that resolves to the path of the package. Everything seems to work correctly, i.e. I can add an artifact to the consumable configuration, declare a dependency on the subproject using a dependency scope dependency, and read the path of the package from a resolvable configuration. The only thing that doesn't seem to be working is automatically triggering the task that builds the artifact just by declaring the dependency on the subproject. In other words, given the following:

// plugin
val declarable = project.configurations.dependencyScope("pythonScope") {
    it.attributes {
        it.attribute(Usage.USAGE_ATTRIBUTE, project.objects.named(Usage::class.java, "python"))
    }
}

val consumable = project.configurations.consumable("pythonConsumable") {
    it.attributes {
        it.attribute(Usage.USAGE_ATTRIBUTE, project.objects.named(Usage::class.java, "python"))
    }
}

val resolvable = project.configurations.resolvable("pythonResolvable") {
    it.extendsFrom(declarable.get())

    it.attributes {
        it.attribute(Usage.USAGE_ATTRIBUTE, project.objects.named(Usage::class.java, "python"))
    }
}

// producer project
artifacts {
    add("pythonConsumable", pythonPackage) {
        builtBy(buildPythonPackage)
    }
}

// consumer project
dependencies {
    pythonScope(projects.grpc.stub.python)
}

...

// within the `testResolution` task
val res = project.configurations.getByName("pythonResolvable")
res2.resolvedConfiguration.resolvedArtifacts.forEach {
    println(it.file.path)
    println(it.file.isFile)
}

I can run

buildPythonPackage

and

"testResolution"

tasks and everything works, but from a clean build, if I only invoke

"testResolution"

,

buildPythonPackage

is not invoked. Am I missing something, or why is not the package being built since it's been explicitly declared which task generates the artifact?

Another beginner's question: what's the difference between

configurations.all {
  resolutionStrategy {
    force("foo:bar:1.0")
  }
}

and using a platform

dependencies {
  constraints {
    api("foo:bar:1.0")
  }
}

is it possible to do this but with a plugins block rather than a buildscript? I am not able to find the substitute api for

pluginManagement

in settings.gradle.kts..

I have an issue relating to failing to generate Kotlin accessors, owing to some kind of dependency issue. It's rooted in code that looks like this

val configuration = configurations.register("something") {
  defaultDependencies {
    add(project.dependencies.create("foo:bar:1.0"))
  }
}

ant.taskdef("someAnt", "my.ant.AntType", configuration.get())

The error is resulting from a

ModuleNotFoundException

, saying

Cannot resolve external dependency foo:bar:1.0 because no repositories are defined.

Yet, the plugin is being applied (transitively) to a project for which repositories are defined. Anyone have any insight?

when declaring a dependency from a version catalog that requires a classifier, you can use the following syntax:

implementation(variantOf(libs.myLib) { classifier("myClassifier") })

How can I do the same inside the dependencies block of a

JvmTestSuite

?

Anyone ever setup an artifact transform so that you can consume an android AAR from a regular JVM project? Usecase: writing a KSP processor that I want the tests to be able to compile using some androidx api's on those classpaths

Hi folks, I have a request regarding

ConfigurableFileCollection

. It's been several times that I have a similar use case. In the context of GraalVM native build tools, there's a classpath for compilation, which is built from several different things. It is therefore using

ConfigurableFileCollection

. The user may add whatever they want in there, a

Configuration

, a

File

, ... However, for some features, I have to reason about the kind of files that are part of this collection. In particular, I need to be able to reason about the GAV coordinates of an artifact. Obviously, a

File

doesn't give us this information. The closest thing that I can use is an

ArtifactView

, but it only works for things that I handle, e.g, if I configure the default classpath to be derived from a

Configuration

, I can reason about it, but who knows what the user would do: clear the collection, add files, add more `Configuration`s, etc. Is there any chance we can get an API which wouldn't be just

getFiles()

but something richer that we can reason about?

Hi All, A question about the JVM Test Suite Plugin's handling of dependencies. I can see the

testImplementation

configuration

extendsFrom

the project's

implementation

configuration (and in turn,

api

). However, for any other test suite I add, that's not the case, and the docs show adding an

implementation(project())

dependency instead. I believe I understand why the project dependency isn't added automatically, i.e. to give build authors more flexibility for their test suite dependencies. My question is, why a project dependency instead of extending from the project's

implementation

configuration like the built-in unit test suite does? I'm looking to more thoroughly understand the design difference.

I'm curious why was invented such naming system inside of the version catalog (TOML) where dependencies using "-" like

androidx-compose-bom

and inside of Gradle scripts "-" are replaced by "." this is so awful solution and it is used everywhere 😭 It completely prevent to use code suggestion / auto completion inside of IDE. When you have something like

androidx-compose-material3-adaptive-navigation

and you don't remember the whole name, just know that it is navigation, you are lost. With

androidxComposeMaterial3AdaptiveNavigation

, you can write just

nav

and you are done. Or if you want to add some dependency even before project is properly synced, with camel case you can just copy&paste it, with current format is a huge pain. The same if you are using currently popular

build-logic

in project plugins to simplify multi-module setup. Then you need to use

add("implementation", libs.findLibrary("androidx.compose.material3.adaptive.navigation").get())

And you need to manually handle replacing

-

by

.

. Or when you want to found where it is used, you cannot just select text and search. Is there any petition for stop using

a-b-c

syntax. I would sign in immediately 😉.

* What went wrong: A problem occurred configuring project ':flutter_inappwebview'.

Could not create an instance of type com.android.build.api.variant.impl.LibraryVariantBuilderImpl.

> Namespace not specified. Specify a namespace in the module's build file: /Users/parthas/.pub-cache/hosted/pub.dev/flutter_inappwebview-5.8.0/android/build.gradle. See https://d.android.com/r/tools/upgrade-assistant/set-namespace for information about setting the namespace. If you've specified the package attribute in the source AndroidManifest.xml, you can use the AGP Upgrade Assistant to migrate to the namespace value in the build file. Refer to https://d.android.com/r/tools/upgrade-assistant/agp-upgrade-assistant for general information about using the AGP Upgrade Assistant. is anybody facing this issue? Provide any solution for this

Can I disable the global dependency substitution rules only for a given groupId? i.e. Disable included builds substitution but only for a given group?

Am I supposed to see a warning when using an artifact that was relocated using maven relocations (https://docs.gradle.org/current/userguide/publishing_maven.html#publishing_maven:relocation)? IntelliJ doesn't seem to show anything, neither Gradle. Am I missing something here?

Is anyone here aware of tooling that uses

pom.license.url

in addition to

pom.license.name

? We're considering removing the url from our poms because they duplicate information and make the pom validation somewhat harder: url can take many forms while

license.name

can point to a well defined SPDX id. Are we breaking someone's workflow by doing this?

Reposting here from #CAHSN3LDN, as this may be the more proper channel: Hey folks! We're looking at setting up some dependency [signature] verification for our repo (per dependency verification), but it doesn't look like signature verification accounts for subkeys? For example, if we want to trust all the public subkeys for

eb4c1bfd4f042f6dddccec917721f63bd38b4796

on the ubuntu keyserver, we'd have to manually add a

<trusted-key>

entry per subkey. I can see the value in doing this, since subkeys are usually rotated- but from a consumer standpoint, this seems verbose. I guess a better question would be, is there a way to have gradle automatically add subkeys of a trusted key to the metadata xml file? I understand you can run

./gradlew --write-verification-metadata pgp,sha256

to automatically populate the metadata, but that can potentially introduce excessive positives for untrusted artifacts. Ideally, we want to automatically update the metadata file, but only for updating trusted keys per remote key servers. Am I missing some feature or misunderstanding something about the process here?

Can I declare a repository for a single configuration? (I don't want to pollute the user repositories with a repository that is used for very niche case)

I know I can use capability-aware for more complex dependency resolution situations. However, from what I can tell, this also works out to "one artifact is resolved to a single variant". I'd like to provide optional functionality from a single artifact, so I'd like to let users depend on multiple variants of that artifact (which they will enable by using a plugin which sets everything up). Is this possible? If so, by which mechanism?

I have a configuration that extends another one, however the child configuration has additional attributes that not all dependencies declared in the parent configuration have. Currently, Gradle crashes when it cannot find an artifact for the child configuration. However, I would prefer Gradle to ignore dependencies declared in the parent configuration that cannot satisfy the child configuration. Or, said another way, I want the child configuration to depend on anything declared in the parent configuration but only if they have a variant that satisfies the child configuration's attributes. Is this possible?

Whats the status of the

DependencyCollector

&

DependencyModifier

etc APIs? Its been incubating for a while & entire ecosystem is in shambles regarding dependencies (*_stares directly at KGP_ 👀), Any blockers to stabilizing these APIs?

Hi, Gradle folks! Can someone share wisdom about migration from

Configuration.getResolvedConfiguration()

to

Configuration.getIncoming()

? I've found an observable behaviour change, even though it's a bit small: if one adds file dependencies (like

implementation(files("libs/a.jar"))

): • Old API wouldn't return them from

ResolvedConfiguration.getResolvedArtifacts()

but would return them in

ResolvedConfiguration.getFiles()

, • But new one will return both from

ResolvableConfiguration.getArtifacts()

, but for standalone files their

ResolvedArtifactResult.getId()

would be (at 8.12 at least) of

org.gradle.internal.component.local.model.OpaqueComponentArtifactIdentifier

, and the only things accessible without using the internal class are `toString`/`displayName` and friends, and they aren't fully informative, for me they only contain file name. On older API I've run through

ResolvedConfiguration.getFiles()

and for all files not found in

.getResolvedArtifacts()

I'd mark them down for my usage by their path, but in new API those are in artifacts, and the component name lacks full path.

8.10 docs had a nice section about the attribute matching algorithm: https://docs.gradle.org/8.10/userguide/variant_attributes.html#sec:abm_algorithm I can't find it anymore, does anyone know where it's gone?

Probably a long stretch but did anything change in 8.12 regarding included builds and plugins ? My build fails with:

Included build 'apollo-kotlin' not found in build 'apollo-kotlin'

Moving away from

pluginManagement { includeBuild() }

/`plugins { id() }` to

includeBuild()

/`buildscript { dependencies {} }` fixes the issue but it feels really weird. Does anyone have any clue what could have gone wrong here?

It appears that kotlin-dsl, in combination with

failOnVersionConflict

resolution strategy, and dependency locking

lockAllConfigurations

turned on, ends up requiring also the exact same version of Gradle to reproduce the same build. This appears to be because the kotlin-dsl plugin aggressively writes the stdlib and other dependencies into the graph:

* What went wrong:
Execution failed for task ':dependencies'.
> Could not resolve all dependencies for configuration ':compileClasspath'.
   > Conflicts found for the following modules:
       - org.jetbrains.kotlin:kotlin-stdlib between versions 1.9.24 and 1.9.22
       - org.jetbrains.kotlin:kotlin-reflect between versions 1.9.24 and 1.9.22

In order to correctly reproduce a Gradle build that uses Kotlin, is it also required that I use the exact same version of Gradle to invoke the exact same Kotlin compiler as well? Or is it possible to ask Kotlin to use different dependencies in my project?