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.

Why can the version constraints here not be satisfied? There is one strict version and otherwise non-strict, so the strict one should be used, shouldn't it?

> Could not resolve all files for configuration ':foo:compileClasspath'.
> Could not resolve commons-io:commons-io:{strictly 2.11.0}.
     Required by:
         project :foo > project :bar
> Cannot find a version of 'commons-io:commons-io' that satisfies the version constraints:
           Dependency path 'my.group:foo:1' --> 'my.group:bar:1' (apiElements) --> 'commons-io:commons-io:{strictly 2.11.0}'
           Dependency path 'my.group:foo:1' --> 'my.group:bar:1' (apiElements) --> 'org.apache.poi:poi-ooxml:5.4.1' (compile) --> 'commons-io:commons-io:2.18.0'
           Dependency path 'my.group:foo:1' --> 'my.group:bar:1' (apiElements) --> 'org.apache.poi:poi:5.4.1' (compile) --> 'commons-io:commons-io:2.18.0'
           Dependency path 'my.group:foo:1' --> 'my.group:bar:1' (apiElements) --> 'org.apache.poi:poi-ooxml:5.4.1' (compile) --> 'org.apache.commons:commons-compress:1.27.1' (compile) --> 'commons-io:commons-io:2.16.1'
           Dependency path 'my.group:foo:1' --> 'my.group:bar:1' (apiElements) --> 'org.apache.xmlgraphics:batik-svg-dom:1.18' (compile) --> 'org.apache.xmlgraphics:batik-awt-util:1.18' (compile) --> 'org.apache.xmlgraphics:xmlgraphics-commons:2.10' (compile) --> 'commons-io:commons-io:2.11.0'

A feature request about toml - I would like to specify configuration in bundle section. As example, I have dependencies and lint rules made by community (not shipped with libraries). It would be great to define bundle with library as implementation configuration and lint dependency as check configuration. What do you think?

Is there a way to figure out what all public repository for dep resolution are added in the project, apart from looking at where a particular dependency is getting pulled from.

Is there a way to somehow transform an optional (transitive) dependency in the pom.xml of a (direct) dependency into a dependency constraint? Context: org.jooq:jooq has an optional dependency on jakarta.xml.bind:jakarta.xml.bind-api, optional in this case because that dependency is incompatible with Java 8, and it's only used for its annotations so shouldn't be needed at runtime (unless you want to take advantage of them, in which case you'd have to somehow have a dependency on them anyway). The problem is that JavaC emits a warning when they're not in the compile classpath. My idea was to use the org.gradlex.jvm-dependency-conflict-resolution plugin to "patch" org.jooq:jooq and declare jakarta.xml.bind:jakarta.xml.bind-api as compileOnlyApi dependency, but without specifying the version; ideally it could then use the one from the pom.xml as the default (through a dependency constraint, unless I have a dependency on it by other means), and I wouldn't have to hardcode the version and update it at the same time that I update org.jooq:jooq. This also means this "rule" could be "bundled" into a plugin, irrespective of the version of org.jooq:jooq used by the project in the end. (for now, I simply declare a compileOnlyApi dependency with a because() to document it, and I thus have a version declared in my catalog; this is very explicit and "noisy"; and it's ok because it's only happened once) Also, WDYT, should this be the default behavior of Gradle? (to have optional dependencies participate in version resolution)

I’m trying to migrate to dependency verification, and I find it hard to use 1. It has

trusted-keys

and then it might have

component/artifact/pgp

below. How do they differ?

<trusted-key id="0D35D3F60078655126908E8AF3D1600878E85A3D" group="io.netty" name="netty-bom" version="4.1.104.Final"/>

<component group="io.netty" name="netty-bom" version="4.1.101.Final">
         <artifact name="netty-bom-4.1.101.Final.pom">
            <pgp value="0D35D3F60078655126908E8AF3D1600878E85A3D"/>
         </artifact>
      </component>

What is the reason Gradle adds a component-related record while there’s

trusted-key

for it? 2. It looks like

trusted-key

and

component

duplicate information. 3. The entries in

trusted-key

are not consistent. Sometimes they include only group, sometimes they include component, and sometimes they include the version as well:

<trusted-key id="187366A3FFE6BF8F94B9136A9987B20C8F6A3064" group="com.google.protobuf"/>
         <trusted-key id="190D5A957FF22273E601F7A7C92C5FEC70161C62" group="org.apache" name="apache" version="18"/>
         <trusted-key id="19BEAB2D799C020F17C69126B16698A4ADF4D638" group="org.checkerframework" name="checker-qual"/>

Frankly, I find it quite surprising. Should it rather be configured with a setting like “trust PGP for group/group+artifact/group+artifact+version”? 4. It is strange

--write-verification-metadata

requires

pgp,sha256

arguments. Should it rather be included into the

verification-metadata.xml

? My understanding is that

verification-metadata.xml

should be self-sufficient to specify what it actually verifies. Then

--write-verificaiton-metadata

should be idempotent. I’m using Gradle 8.14.3 if that matters

Is this the right place to ask for extending DependencyHandler to have in addition to

DependencyHandler#addProvider(String,Provider<Object)

also support sth like

DependencyHandler#addProvider(String,Provider<Collection<Object>>)

We try to be good citicen using the provider api where possible but often we break at certain gradle api boundaries. E.g. we have a

Provider<Collection<String>>

representing a set of dependencies. what I now end up doing is mapping this explicitly to a dependencySet "early" and do

myConfiguration.defaultDependencies(t -> {
                psService.get()
                    myDepsProvider.get()
                    .forEach(path -> t.add(depsHandler.project(Map.of("path", path))));
            });

which feels just wrong and a misuse of defaultDependencies. Ideally I'd be able to do

dependencyHandler.addProvider("myConfiguration", myDeps.map(deps -> deps.collect(d -> dependencyHandler.project(Map.of("path", d)))))

Or do i miss something here to make that simpler?

is there a way to check the actual requested attributes in a ComponentMetadataRule? I want to use ComponentMetadata rules to disable transitive dependencies at all, but keep it for now for my codequality configurations like

checkstyle

and

spotless

. I wonder if there's a way or if I would need a different approach like using a specific variant for those configurations or something like that.

I have an issue which doesn't seem to be well documented, so I thought I'd ask in here. First, I'm trying to create a merged java-platform BOM that pulls in a BOM from an upstream framework (Quarkus) and merge it with another BOM that I built that has other tools selected above and beyond the Quarkus BOM. So, again, I effectively have a "merge" BOM, which has a platform dependency on the Quarkus and my BOM. Second, I am using "failOnVersionConflict" to check where conflicts between the BOMs occur and silent upgrades might break a transitive dependency. The problem occurs when I try to use this "merge" BOM in another project. For example, if I use "io.quarkus:quarkus-agroal" I get the correct version thanks to the platform BOM, but it eventually pulls a transitive called "org.reactivestreams:reactive-streams". The version pulled transitively is 1.0.3, but the BOM is asking for 1.0.4. I added an extra constraint that strictly requires 1.0.4 in the "merge" BOM to override the transitive dependency, but I still get the version conflict. In this scenario, how does Gradle expect me to resolve transitive conflicts in a way that is reusable?

Greetings! We’re using the java-platform pattern to manage dependency constraints in our mono-repo. So a top level project with many subprojects that have the platform as

implementation(platform(project(':path:to-platform')))

Is there a way, other than enabling

allowDependencies

, to enforce a verison across all subpackages for another project without specifying each one individually? Like take jackson suite of packages or awssdk? Something similar to the bom constraint pattern you can use

implementation(platform('com.fasterxml.jackson:jackson-bom:2.15.2'))

Does the order in which dependencies are displayed in the build scan represents the files collection order that is returned from the related

Configuration

?

Do you list also transitive dependencies that are used in module? Personally, I'm a fan for this.

any ideas?

has anything changed with

mavenLocal()

? I see that the section “the case for mavenLocal()“ was removed in this commit which went was part of the

8.10

release. The current version of the page has no discussion, nor does it mention repository content filtering at all

Can I use different attributes for resolving the transitive dependencies of a dependency vs the attributes used to resolve the dependency itself?

Hello. I tried to prepare

Isolated Projects

feature on my sample android app project. This app project has

convention plugin

which has dependencies with AGP, KGP, KSP and etc... After migrated

subprojects

to

gradle.lifecycle.beforeProject

(as recommended), I found all plugins should be loaded which have dependent with convention plugin on

settings.gradle.kts

https://github.com/ganadist/minimal-reproducible-example/commit/1ab2053d43b933554b3b273b3d2c43b8cd85e8f9 After the migration, I did verify that the build works, but dependency management of plugins has become very cumbersome. 😞 I want to know if the method I used is correct and if there is a better way.