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?

I've got a subproject,

:app

, which has the spring boot plugin applied, so it generates a runnable jar artifact from

tasks.bootJar

into

layout.buildDirectory.dir("libs")

- in practice,

app/build/libs/app-boot.jar

. It also has the

application

plugin so it generates

app/build/libs/app-plain.jar

(which does not contain all the other deps). I would like the parent project to copy

app-boot.jar

into is build dir -

layout.buildDirectory.dir("artifacts")

, in practice

build/artifacts/app-boot.jar

. Non-working attempt in thread...

I have an issue - I'm trying to add org.ow2.asmasm9.7.1 as a dependency, and my project is intended to be compatible with java 8. ASM claims to support java 1.5+, but gradle fails to resolve it, claiming it requires java 11 (they do compile on java 11 and then use retrofitter), despite there being no gradle module info published on maven. What can I do to force gradle to resolve it?

Nevermind, I forgot I used composite build to add asm source foir reasons I don't remember

Before the world of

platform(<dep>)

(Gradle 2.8 to be precise), did Gradle properly work with importing boms? I'm working with an old build that I cannot upgrade. The POM of one of the deps contains:

<dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>my.group</groupId>
        <artifactId>myPlatform</artifactId>
        <version>1.2.3</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>

That platform contains a

dependencyManagement

element as expected, however the versions listed appear to have no influence on the resolved dep tree. I cannot recall whether such an old Gradle version fully resolves dep management sections or not, and I'm not sure if I've got something broken in the build or if it's just the Gradle version.

I have an Android library that depends on a BOM. When I publish the library, I generate a pom.xml which contains the BOM dependency itself and the different dependencies from that BOM. The dependencies don't specify versions as I haven't figured out a way to extract the versions from the BOM. When I import the library in another project, Gradle complains it cannot find dependency with empty version. But I thought gradle will be smart enough to notice these empty versions belong to a BOM so it should resolve them from the BOM

Hi everyone. I use Type-safe project accessors for dependency declarations but there's a problem with that. When I want to speed up gradle sync and exclude some modules from settings.gradle plus use a condition to "remove" this module dependencies out from dependency tree (for example for a specific build variant), gradle sync fails, because despite removed modules by condition, gradle still needs to know this modules for type-safe access. Is there any way to do it with type-safe access (except use the old dependency declaration)? settings.gradle.kts:

// include(":A") // Commented out
// include(":B") // Commented out

build.gradle.kts:

kotlin.sourceSets {
    if (isABEnabled()) { // false
        val commonMain by getting {
            dependencies {
                implementation(projects.A) // Gradle sync fails
                implementation(projects.B) // Gradle sync fails
            }
        }
    }
}

The old dependency declaration works, but I would like to use type-safe access everywhere:

kotlin.sourceSets {
    if (isABEnabled()) { // false
        val commonMain by getting {
            dependencies {
                implementation(":A") // Gradle sync works
                implementation(":B") // Gradle sync works
            }
        }
    }
}

Hi all, I am splitting my tests into different modules and I came across JvmTestSuite. I've added it to my build.gradle.kts. But I'm having the issue that the new JvmTestSuite does not have access to internal classes. Is it possible to get this done?

testing {
    suites {
        // Configure the default test suite (unit tests)
        val test by getting(JvmTestSuite::class) {
            useJUnitJupiter()
        }

        // Register an integration test suite
        register<JvmTestSuite>("testGraphql") {

            // Define test sources directories
            sources {
                kotlin {
                    srcDir("src/testGraphql/kotlin")
                }
                resources {
                    srcDir("src/testGraphql/resources")
                }
            }

            dependencies {
                implementation(project())
            }

            // Configure the implementation configuration to extend from the main implementation
            configurations {
                // Make testGraphqlImplementation extend from implementation
                named(sources.implementationConfigurationName) {
                    extendsFrom(configurations["implementation"])
                    // Also extend from testImplementation to get all test dependencies
                    extendsFrom(configurations["testImplementation"])
                }
                // Make testGraphqlRuntimeOnly extend from runtimeOnly
                named(sources.runtimeOnlyConfigurationName) {
                    extendsFrom(configurations["runtimeOnly"])
                    extendsFrom(configurations["testRuntimeOnly"])
                }
            }


            // Test framework
            useJUnitJupiter()


            targets {
                all {
                    testTask.configure {

                        // Make integration tests run after unit tests
                        shouldRunAfter(test)

                        // Only run tests if they've changed
                        outputs.upToDateWhen { false }
                    }
                }
            }
        }
    }
}

tasks.named("check") {
    dependsOn(testing.suites.named("testGraphql"))
}

tasks.withType<Test> {
    useJUnitPlatform()
}

Also I was having an issue where I have some duplicate test resources, I have solved it with this. but ideally I wouldn't need a duplicate strategy, it would just not put the the resources from a different jvmtestsuite on the classpath, that way they are seperate but can exist in the same project, but I don't know how to arrange this.

tasks.named<ProcessResources>("processTestResources") {
    duplicatesStrategy = DuplicatesStrategy.INCLUDE // Options: INCLUDE, WARN, EXCLUDE
}

tasks.named<ProcessResources>("processTestGraphqlResources") {
    duplicatesStrategy = DuplicatesStrategy.INCLUDE // Options: INCLUDE, WARN, EXCLUDE
}

Hey folks, I recently learnt that Gradle has support for source dependencies https://blog.gradle.org/introducing-source-dependencies. Was curious to know if any one uses this? How has your experience been? I wanted to understand if gradle can also support behaviour similar to go's package manager where we could use a git repo for the code and then build it locally before using.