From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

Before I left, the plan was to eventually embed this plugin in the Gradle Build Action so it would be enabled by default.

<https://github.com/gradle/gradle-build-action>

I have the multimodule project, however, one module is SDK and is used by other modules as a binary dependency from the maven repository. I want to update kotlin version only for SDK. Before for other dependencies, I was making a duplicated dependency with newer version that I only was referencing in the sdk module. For the kotlin I need also to use a newer plugin version. However, this plugin is used in all other modules. Is there a way to have two plugins of the different version in one multimodule project? We still use the legacy declaration of the plugin in the `buildscript` lambda.

I'm not sure there's a large enough need for a specific API for that. Is there something wrong with iterating over all the entries in a catalog?

That is indeed what I am doing

 <https://github.com/JavierSegoviaCordoba/gradle-extensions/blob/main/gradle-extensions/gradle-version-catalog-extensions/main/kotlin/com/javiersc/gradle/extensions/version/catalogs/VersionCatalogs.kt|https://github.com/JavierSegoviaCordoba/gradle-extensions/blob/main/gradle-extensions/gradle-version-catalog-extensions/main/kotlin/com/javiersc/gradle/extensions/version/catalogs/VersionCatalogs.kt>

do the referenced files exist on the repository?

I am parallely checking with the owners who are the owners to publish the results in the arm respository..I am using cyclonedxbom to detect vulnerabilites.

I tried other option using syft &amp; grype where its not throwing these errors

but here also its scanning same repositories thats mentioned in build.gradle file

any idea why its not throwing these errors when using syft &amp; grype but throwing errors when using cyclonedxbom

as I haven’t used any of those solutions, I have no clue

I am facing POM issues in dependency track pipeline stage

Please let me know if anyone faced above error

Please use a thread, not individual messages, makes it easier to follow and reference later.

The error you get basically says your repository missed metadata files, so resolution cannot happen.

so you should check if the libraries were correctly published and if not, fix them.

Is it developer who will publish the libraries ?

I suggest you read the docs at <https://docs.gradle.org/current/userguide/dependency_management.html> to get an understanding of dependency management.

you have a dependency on an internal library, and it looks like this library is not published correctly on your company repo.

ok...thank u melix for your response..i am following up with the concerned owners of these repositories...currently i am using cyclondxbom plugin

Probably the falling tool depends on proper Maven metadata files and the other is not.

I am using cyclonedxbom plugin where its throwing below error -

Unable to resolve POM for com.XXXXX.lwac:lwac:6.7.0-rc5: org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration$ArtifactResolveException: Could not resolve all files for configuration ':detachedConfiguration77'.

A `force` is a hammer, which is also purely local to the project being resolved. It will ignore anything else and is somehow subject to ordering issues. A `strictly` is a proper dependency version declaration, which is used during resolution as any other information. For example it will participate in conflict resolution and fail if it finds conflicting `strictly` clauses. Also it's _published_, which means that consumers will get the strictly.

In other words, `strictly` is a better designed solution for `force`.

this is in the context of an app, so I'm not concerned about publishing the information. Is there any performance impact? Right now we have a base plugin that's applied to every subproject in our project, so they all get the force rule. Would it make any measurable difference to replace that with a strictly constraint?

I suspect a `force` would be faster, but no numbers to back that statement.

although I'm wondering if this is on the order of milliseconds or microseconds or something. I know that AGP applies constraints from the runtime classpath to the compile classpath already, so our build is _chock full_ of constraints due to that

Gradle should really remove the `force` option. Every time I've asked I've been told not to use it

I'm not seeing a good reason _why_ tbh. Saying that constraints are "better designed" is nice, but not really compelling from an end-user perspective

it's like how the docs say you shouldn't use `getPlugins()` but instead `getPluginManager()` without any explanation why the latter should be preferred

I'm sorry I thought I was clear: `force` is a hammer which is inherently broken. Depending on when the force is seen first (when it's on a dependency), you get different results. When it's on a configuration, it doesn't propagate to consumers, which is, IMO, another reason to avoid it. So, prefer `strictly`. This is the only mechanism which is consistent and would give you better error messages in case of conflicts.

I hear you. Since we apply the force rules universally, I don't think we have the problem of consumers not seeing it. I agree that we should migrate. This is about prioritizing work

and also fully understanding the space for the inevitable questions when I _do_ make this change

Isn’t _force_ deprecated to indicate at least that is is to be fully replaced by _strictly_?

`force` is deprecated on an `ExternalDependency`, but not on a `ResolutionStrategy`.

What do you mean with that? Do you have an example of what you mean?

Yes. Afaik, right now you can use version catalogs for library dependencies but not for module dependencies. You gotta reference them by name at the moment like `implementation(project("module-name))`. Are there plans for defining these in modules in version catalogs?

I don't think so, it is neither a dependency of the build, nor does it have a version.
And more importantly you can already let Gradle generated accessors for them. It is just an experimental feature you have to enable on your settings script right now.

<@U01UF86KJD9> you are probably looking for type-safe project accessors. :wink:
`enableFeaturePreview("TYPESAFE_PROJECT_ACCESSORS")`

Hi All...Do anyone have good  links to explore on  syft and grype tools ?

Constraint on `runtimeClasspath` should break a build so  `apiElements`/`runtimeElements` should be broken too. I would think that it should be enough to prevent the sqlite impl propagation. I'm not sure if you should care at all about `compileClasspath`/`compileOnly`/`compileOnlyApi` in this case.

If you use a constraint on the `implementation` it also should break the build preventing propagation if the dependency was brought transitively via `implementation`'s direct dependencies' afaik.

Do you want to forbid sqlite in the current module or taint all dependent projects to prevent them using sqlite through other deps? Later case seems more suited for platform with reject constraint.

right now we're using the convention plugin approach, so I can add the constraint to my plugin and ensure it is present in every project of the build. Adding it to a platform also sounds like it would make sense

I'm still slightly confused about how these constraints propagate, both through a single project and an entire build, as it turns out. Why doesn't putting the constraint on `implementation` also taint `testImplementation` (testCompileClasspath and testRuntimeClasspath), for example?

constraint on `implementation` should apply to `testImplementation` in the same project, at least for a platform applied to the project

not sure how constraints are propagated between dependency bags and resolvable configurations

I either use them for the current project or in the platform definition that has to be applied to bunch of configurations

with the constraint as indicated in my code snippet, `compileKotlin` will fail in the expected way, but `compileTestKotlin` will not

to be clear, I do not _want_ it to fail at test time. I want my tests to use this dependency

I've been using this as a reference. It suggests that testImpl should inherit from impl.

I should be more clear though, that I'm in an Android project. Nevertheless, I think it follows this form

yeah, I use the same doc page as reference)
but I'm not familiar with agp at all

maybe one of Gradle devs familar with constraint propagation would point to the right issues and/or code

or I could look into the gradle source tomorrow if you ping me and I have a bit of time for experiments

a-ha, I was wrong, I wasn't using my constraint for Reasons. Tests do fail with the constraint as set up. At least that makes sense. I think I need to be more explicit and set it on the compile and runtime classpaths, since they should be independent of the test classpaths. Let's find out!

I do find the constraint docs a bit underwhelming, so if  gradle dev saw this and chose to enlighten me, I would gladly accept that :slightly_smiling_face:

i find experiments later backed by some tests to be the best assurance but good kick in the right direction is almost always enlightening

If you add the constraint in all of your projects through a convention plugin, `implementation` is the best choice imo. You won’t win anything by using `api` . Using `api` would mean that the constraint would propagate, at compile time, as “transitive dependency” to all *direct* consumers of a project (that’s what apiElements is for). But you would still have to add it to all projects as there is nothing that would allow you to just add it to *one* project and then propagate it everywhere at compile time. Hence, I would stick with `implementation`.

The `testImplementation` -&gt; `implementation` is one of these things that were done in the early days of Gradle to mimic Maven behaviour. (Well to be correct it was `testCompile` -&gt; `compile` back then, but this was preserved probably to not break to many existing things.). I wish this could be removed, but I doubt it will every happen (backward compatibility). Imo it meddles with the isolation of variants/sourceSets and makes things harder to understand. It would be much clearer (imo) if tests won’t automatically see all dependencies of `main` . In the end, if something is `implementation` for `main` , why should the test see it (it’s supposed to be internal then).

And if you declare a dependency from `test` to `main` (ie, _test variant_ depends on _main variant_ - `testImplementation(project(path))` - test will not only see your main code, but also everything that is `api` . And ‘test’ would be like a _feature variant_ that behaves similar to other feature variants. It’s still kind of complicated :slightly_smiling_face: but it would be consistent.

If you create a new Source Set (or Test Suite), you won’t have this relationship, unless you manually add it. And you can do the consistent setup. That’s why `test` is special in this regard and that is why other test setups (Kotion, Android) maybe do not have this relationship.

thanks Jendrik! so, based on all that, and considering I'm talking about an android project and must not forbid this dependency for test purposes, do you agree I should use compileClasspath and/or runtimeClasspath?

You indeed need to put the constraint in a configuration that does not impact tests.
I would recommend creating a dedicated configuration for this and have both `compileClasspath` and `runtimeClasspath` extend from it.

let's see if I understand the suggestion:

as testImplementation inherits from implementation, any constraint you add to implementation affect tests.

you can create another configuration that inherits from implementation (and compileOnly and runtime if needed) and apply the constraint

oh, no, actually the suggestion fro Louis is not that, bat adding your configuration with the constrain to compileClasspath and runtimeClasspath

The motivation is to always separate _bucket_ configuration - where you declare dependencies and constraints, cannot be consumer or resolved, from the other ones - the consumable or resolvable ones.
It also helps thinking about variant attributes because declaring attributes on bucket configurations has no effect, since they are not carried over.

"noTestImplementation" or "implementationOnly" :joy:

Well in this case, I would name it: forbiddenDependencies :wink:

they are not forbidden for tests! (but I was just kidding anyway)

Right, `forbiddenRuntimeDependenciesThatAreAllowedInTest` :stuck_out_tongue:

I must say the whole "test" idea is quite messy
it's used as default unitTest, so if you create more test sourcesets/configurations you have to create your baseTest configuration, duplicate everything or use test as base for your integration tests.
and then..most plugins assume everything is only in "test" without providing flexibility to have integrationTest for example. Even JaCoCo and test-fixtures are only configuring `test` IIRC

(sorry, I don't want to change the topic)

I'm at a bit of a loss for the moment. Despite putting the constraint on the debugTestRuntimeClasspath, my tests are failing because they can't resolve all the required dependencies. I don't understand why the test runtime classpath (debugUnitTestRuntimeClasspath) is seeing this constraint. It does not (directly) extend debugTestRuntimeClasspath...

Printing the extendsFrom hierarchy confirms (I think) that my constraint shouldn't propagate
```- debugUnitTestRuntimeClasspath extendsFrom:
  * testDebugRuntimeOnly
  * testDebugImplementation
  * testRuntimeOnly
  * testImplementation
  * debugUnitTestRuntimeOnly
    * testRuntimeOnly
    * testDebugRuntimeOnly
  * debugUnitTestImplementation
    * debugUnitTestApi
      * testApi
      * testDebugApi
    * testImplementation
    * testDebugImplementation```

Maybe in the Android setup “unit test” actually dependents on the corresponding “main” variant(s) which brings in the constraint in your case? Where do you define it now? Is it only on `*Classpath`  or also on `*Elements` ? The later would make it propagate. A build scan (or running `dependencies`) should give more insights.

I followed Louis' suggestion and put it on a new configuration which I then had `debugRuntimeClasspath` extend from. The build scan was not super helpful; I still think these views have usability issues, and recall I used to teach people how to read this stuff. It clearly showed that the dependency was only present on `debugUnitTestRuntimeClasspath`, and then a _whole bunch_ of paths to the constraint that I couldn't parse.

Here's a snippet. I've also attached a screencap.
```Dependency path 'register.common.addons:impl:unspecified' --&gt; 'com.squareup.sqldelight:sqlite-driver:1.5.3'
   Constraint path 'register.common.addons:impl:unspecified' --&gt; 'register.common.addons:impl:unspecified' (debugRuntimeElements) --&gt; 'com.squareup.sqldelight:sqlite-driver:{reject all versions}' because of the following reason: &lt;omitted for brevity&gt;'
...```
The "dependency path" in question is `testImplementation com.squareup.sqldelight:sqlite-driver:1.5.3`

Does `(debugRuntimeElements)` imply that my test classpath inherits from the runtime classpath and therefore inherits the constraint as well? I could believe it, even though my code walking the `extendsFrom` relationship doesn't show it and it also conflicts with what I'd expect from the relationships described in the java-library plugin docs. I know those aren't exactly relevant for Android, but I was hoping (sigh) that Android was sane here

I think Jendrik is right there. It looks like a combination of two things:
• Android uses a project dependency to get the main component in the test classpath
• Android might define `debugRuntimeElements extendsFrom debugRuntimeClasspath` but that would be really annoying

I have this vague recollection that they might do something like that "manually". I'm pretty sure they don't use `extendsFrom` directly, or maybe it's in an afterEvaluate and it's an ordering issue that I can't see it. Well, I guess this idea is just dead in the water

Android is also doing some kind of “home made consistent resolution” between _production code_ and _test code_ classpathes. IIRC it creates constraints for the test classpathes based on the resolution result. (If that has not been changed by now.) This could also possibly cause this (rather strange) effect.

My ideal would be a way to fail the build for any DIRECT non-test dependencies on `logback-core` and rely on the excludes to manage transitives in the published `pom` / `module`

you should be able to fail the build doing this:
```configurations.all {
   if (it.canBeConsumed) {
        allDependencies.all {
             if (it instanceof ExternalModuleDependency) {
                 if (it.group == 'ch.qos.logback' &amp;&amp; it.name == 'logback-core') {
                     throw new InvalidUserCodeException("Oh noes, you are not allowed to expose logback!")
                 }
             }
        }
   }
}```

so after some shuffling, i ended up with:

```configurations.configureEach {
    val configName = this.name

    // If the bucket is meant for dependency declarations, and is not intended for testing
    // We fail the build if a direct dependency is declared on a banned library
    if (!this.isCanBeResolved &amp;&amp; !this.isCanBeConsumed &amp;&amp; !configName.contains("test")) {
        dependencies.configureEach {
            if (isBannedDependency(this)) {
                throw GradleException(
                    """
                       |Conventions Plugin: Invalid dependency declaration on a dependency banned in this context. Remove dependency declaration: 
                       |    $configName("${this.group}:${this.name}") 
                    """.trimMargin()
                )
            }
        }
    }

    // Handles _transitive_ dependencies, ensuring they are excluded from any generated maven pom files (*Elements
    // configurations) as well as the configurations used when building and running the module (*Classpath
    // configurations)
    // They are though, still allowed to be used for any tests
    if (name == "runtimeClasspath" || name == "compileClasspath" || name == "runtimeElements" || name == "apiElements") {
        sharedLibraryBannedDependencies.entries().forEach {
            exclude(group = it.key, module = it.value)
        }
    }
}```
This seems to fail if any _direct_ dependencies are declared, but not fail for any transitives (e.g. from a platform)… but it also _excludes_ any transitives from being included in the published pom/module.

i used !resolvable and !consumable as the table here: <https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_configurations_graph>

indicates that these are the buckets meant for apps to _declare_ dependencies. your example above i believe would still cause a failure for any transitives (e.g. declared in a platform, but not actually applied to the project) which is just senseless noise - as i really don’t actually care if they’re on the classpath during build, as long as they aren’t exposed to any consumers.

but any further improvement suggestions are much appreciated!

my example doesn't resolve dependencies, so it's not using transitives

it's using the first level dependencies only

Publication repositories support the same credentials as dependency repositories.
Have a look at <https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:handling_credentials>

qq: Can I continue the discussion  or should I move this to <#CKWJRRC66|> where I crossposted this post?

I see you are not in that channel so continuing the discussion here.

Maven provides the option of storing credentials and repository related information in the `.m2/settings.xml`  file. Where this can also be encrypted. As of now, to access this I’d need to depend on a plugin like <https://github.com/mark-vieira/gradle-maven-settings-plugin>.

However considering this is common practice in maven internal publishing I feel that this could be a feature catered too by gradle (or the maven-publish plugin) itself?  The does not fall under the credential types that are listed in doc you shared above.

The relevant section of the settings file is <https://maven.apache.org/settings.html#Servers>

There is indeed no such option in Gradle at this time.

Would it be worthwhile to open an issue on gradle/gradle for this?  I’m not sure if the github repo also covers the maven-publish plugin and if this feature  could be in scope

The repo covers it as well, so you could. Please check there is not an existing one on this topic tough.

I've opened <https://github.com/gradle/gradle/issues/21278> . There was no existing  issue for this.

What is working for me now is
```    tasks.named("publish") { task -&gt;
        configurations.forEach {conf -&gt;
            if (conf.name == "implementation" || conf.name == "api") {
                conf.dependencies.findAll { it instanceof ProjectDependency }.forEach { dep -&gt;
                    task.dependsOn(":${dep.name}:publish")
                }
            }
        }
    }```
But I wonder if there is built-in way to achieve this

Executing tasks between projects would break project isolation though?
you could have a task at the root project  `someTaskForA`  which could then depend on the execution of the same task across multiple projects

```./gradlew --project-dir subproject publish```
untested

```./gradlew --project-dir subproject publish```
no, it only executes publish for subproject, and not for its deps :thinking_face:

&gt; Executing tasks between projects would break project isolation though?
:thinking_face: it's a single project, and I only need to work with a module's subtree, so it shouldn't break isolation.

What you have is not breaking project isolation, because you are not actually accessing any project except your own. If my line didn't work, what you have should, and it looks good.

Maybe my understanding is incorrect, but isn’t a “project” in gradle terminology a module? In that case this is depending on tasks across modules and hence could prevent them from executing in parallel?  Or does project isolation refer solely to isolated root projects?

Project isolation refers to object access, like in threading. You can still have tasks depending on tasks of other projects, but obviously it will have an effect on execution order and parallelism.

See <https://docs.gradle.org/current/userguide/signing_plugin.html#sec:conditional_signing> and <https://docs.gradle.org/current/userguide/publishing_maven.html#publishing_maven:snapshot_and_release_repositories>

I see. So there is only one `MavenPublication` created and we switch between snapshot and release repositories based on project properties or the version suffix.

Yes, and fwiw <https://github.com/gradle-nexus/publish-plugin> does just that (switches target repository URL based on `-SNAPSHOT` suffix in version). If you're planning publishing to a Nexus repository (including the Central Repository through Sonatype OSS), I'd recommended it.

<@UMU9T5J5S>

For the MavenPublication, I do rely on the tag, the tag can be checkout from any branches, then apply the variants e.g dev, alpha, beta, rc <https://github.com/gojek/clickstream-android/blob/main/.github/workflows/publish.yml#L3>

Thanks Raditya! My challenge would now be to how to make this work with credentials in the maven settings file (<https://gradle-community.slack.com/archives/CAH4ZP3GX/p1657692896861049|ref>). It is easier to do if I have multiple repository objects since the credentials differ for each. That’s my next task :slightly_smiling_face:

Also incase I want separate tasks for publishing Snapshot vs publishing release, I would need to create a separate task of type `GradleBuild`  and pass arguments to correctly setup snapshot versions? Is there any other way of achieving this.
I would  prefer not to ask devs to provide CLI args to differentiate between types of releases.

<@U0119NEH98E> qq: So what you shared is for release publications right? Is there a separate mechanism to publish snapshots?

Oh I see, Snapshots are also published via tags.

<@UMU9T5J5S> yes i do utilizing tags for all variants mas. so instead of rely on the repo-regex which can be changes or modified, utilizing tags is more scalable and convenient

or do you really want to publish snapshot based on repo regex?

So I’m trying to move these to separate tasks. i.e. creating separate gradle tasks for publishing snapshots and releases. For which I’d need to modify the version number by some mechanism before the maven-publish plugin’s tasks take over.

My current process was to setup a wrapper task of type <https://docs.gradle.org/current/dsl/org.gradle.api.tasks.GradleBuild.html> which would add the additional project property of “Snapshot” . This would then trigger the snapshot branch of the build(which will append snapshot to the version name and so on). Do you see any thing wrong in this approach?

`a.b.c`are problematic here - would be cleaner if these were part of the module name, or published as variants.  `1.+` will work - for any `a.b.c` which may not be appropriate.

so if artifact name and classifier both can't be used to store `a.b.c` I'm just screwed?

are those artifacts published with a classifier (`a.b.c`), or is that encoded as part of the version?

it's part of the version, the classifiers are `api`, `runtime`, `sources`, etc.

yea.  Gradle will use x.y.z as the version and treat the rest as a qualifier.  to my knowledge, the version resolution is smart - based on modelling the version - not a simple text matching.

you could pull in say `latest.release` , which would presumably match multiple qualifiers, and use the Gradle API to provide the right metadata to allow selection of the ‘right’ `a.b.c`.

Not 100% on target but a start: <https://github.com/jjohannes/missing-metadata-guava>

It is not simply possible, but what you could probably do is to have `2.+` and additionally a resolution rule that rejects any version with the wrong `a.b.c`.

How would I do that? I couldn't find any way to make constraints like that in the version{} block

<https://docs.gradle.org/current/userguide/userguide_single.html#sec:component_selection_rules|https://docs.gradle.org/current/userguide/userguide_single.html#sec:component_selection_rules>

As I said, you need to combine a version constraint with a component selection rule

And it probably does not propagate to consumers, so will only work properly in an end product, not a library

Not without the consumer also having that component selection rule

If I used what you're suggesting, how would I make it work on existing configurations made by other plugins? (modApi, kapt, etc.)
EDIT 1: After some testing, it seems I need to do `configurations.getByname("modApi").extendsFrom(this)` instead of the other way around?

EDIT 2: It seems it's completely ignoring the configuration I gave it, I'm splitting the candidate.version on the "+" and reject if the last part is not a.b.c, but it seems to pick a.b.d as latest version instead

EDIT 3:
```            resolutionStrategy {
                componentSelection {
                    all {
                        throw RuntimeException(candidate.toString())
                    }
                }
            }```
This does not log any errors, and it even still selects the version I'm trying to get it to not select...
With some print debugging, I figured out that resolutionStrategy and componentSelection both run, but all never runs.

I wouldn't use `all` but `withModule`.
And I don't know what you mean with the `extendsFrom`, that does not sound to be any related to your question. With `a.extendsFrom(b)` you configure that all dependencies declared for `b` are also declared for `a`. Just get the configurations you want the configuration on by name or just configure `configurations.all { ... }` if you want it for all configurations.

I guess I can do it all at configuration time, mapping it to my serializable type ¯\_(ツ)_/¯

`configurqtion:allDependencies` / `DependencySet` isn’t supported but you should be able to gather the same information from `ResolvedComponentResult`

I do realize that the point of making dependencies variant aware is to avoid doing the selection by hand :slightly_smiling_face: . But there could be cases where I’d want to explicitly declare the variant to be consumed.

You cannot select a configuration for published dependencies. If you have a multi-project build where one project depends on another, you can use the configuration shortcut instead of going the full attributes way. Unless consumers outside the build should be able to retrieve that variant, then you have to use the full way.

You often select the variant by hand, for example by requesting a specific capability. Only in some cases like when building Gradle plugin variants for different Gradle versions, or building different variants for different Java versions or similar, where the according attributes are already set by Gradle or some plugin, the selection can happen automatically.

Consider the following published depdency
```A
\____B
\____C

D
\___A```
I have `A` which depends on `B` and `C`. I also publish all variants of the 3 libraries. So the `A(debug)` depends on `B(debug)` and `C(debug) ` and similarly for the `release` variant.

Now the debug variant of `D` depends on the debug  variant of `A` and transitively `B` and `C. And similarly for release. Can I request for the `release` of  `A`  in the debug variant of `D` ?

Can you also elaborate a bit on what do you mean by configuration shortcut?  Would that be using `configurationName "group:name:version:classifier@extension"` ?

That sounds like Android, I have no idea about Android. But I *guess* you can choose a different variant, yes.

No, again, you can only depend on a configuration within a multi-project build like `implementation(project(path = ":B", configuration = "foo"))`. And this form is a simplified shortcut for a proper published variant that is also only available within the multi-project build and not published in GMM or other metadata

Yes this is an android related question :slightly_smiling_face:.
However is it possible for me to specify/modify a single attribute which is being asked for? For example, the android gradle plugin adds an attribute of type `"com.android.build.api.attributes.BuildTypeAttr": "debug",` for each variant. Can I not explicitly specify an attribute type while requesting a dependency as a part of the dependencyNotation

Would you have some documentation showcasing this handy? I’m not clear on how to create an attribute value for using as a part of the dependencyNotation

Something like
```implementation("a:b:1") {
    attributes {
        attribute(...)
    }
}```

I don't have the docs at hand, I'm on mobile

Ah no problem .That helps. Thank you!
The signature for the attribute creation is ` attribute(Attribute&lt;T&gt; key, T value)` . And I’m unable to figure out what I can use for the value here. nvm . Let me do some more digging. Thank you very much for help :slightly_smiling_face:

Either the Android plugin exposes its somewhere, or you can alternatively do `Attribute.of(...)` iirc

Our attribute interfaces are public. You can see it here: <https://developer.android.com/reference/tools/gradle-api/7.2/com/android/build/api/attributes/BuildTypeAttr>
Use the method on the `Companion` class to create the right instance of `Atttribute&lt;&gt;` (especially important for the flavor attribute)

Thank you for that!.
I’ve been playing around with this for a while, but with no luck.
Continuing the same example as above ;
I can declare the dep as
```debugImplementation("com.foo.libs:A:1.0.2") {
        attributes {
            attribute(BuildTypeAttr.ATTRIBUTE, objects.named(BuildTypeAttr::class.java, "release"))
        }
    }```
However  running  dependencyInsight for `C` in the project  still shows the debug variant being selected.

I’ve had some progress here though . I now see the release variant of `A` in my dependency graph, however that seems to bring in the `debug` variant of `C`  which IMO should not be the case? Since `A-release` depends on `C-release`.

You need to put the attributes on the `Configuration` that is resolved. These (`debugImplementation`) are just where you set your dependencies. The ones that are resolved are going to be `&lt;variant&gt;CompileClasspath` and `&lt;variant&gt;RuntimeClasspath`

Starting with 7.3 you can find it on `Component`: <https://developer.android.com/reference/tools/gradle-api/7.3/com/android/build/api/variant/Component>

That's not correct, you can set attributes for specific dependencies like I showed him. This overrides the attributes set on the configuration.

The remaining problem is, that not A-release depends on C-release, but A depends on C, and the configuration `debugImplementation` says it needs `debug` so for A it is manually forced to use `release` while C still uses what comes from the configuration which is `debug`.

So updating this for all configurations, does resolve my issue
```configurations.all {
    resolutionStrategy.dependencySubstitution {
        substitute(module("com.foo.libs:A:1.0.2")).using(variant(module("com.foo.libs:A:1.0.2")) {
            attributes {
                attribute(
                    BuildTypeAttr.ATTRIBUTE,
                    objects.named(BuildTypeAttr::class.java, "release")
                )
            }
        })
}```
And repeating this for each of the transitive dependencies does bring in all release variants, however this would require me to know all the  transitive dependencies that `A` exposes and set them to the same variant.
Is this expected though? I had assumed that choosing the `release` variant of `A` would ensure that compatible `release` variants of both `B` and `C` would also be selected

Again, A-release *does not* depend on C-release.
A depends on C (or maybe A-release depends on C, but not A-release on C-release, look at the Gradle Module Metadata to see it)
It would be different when A depended on a specific different _capability_ of C.
But in this case this is not the case, the capabilities are the same, just the attributes are different.
The configuration says that for all dependencies the variant with attribute `debug` should be chosen and you only override it for A.

Also running a dependency insight, gives me this line
```&gt; Task :D:dependencyInsight
com.foo.libs:A:1.0.2
   variant "releaseVariantDefaultApiPublication" [
      com.android.build.api.attributes.BuildTypeAttr  = release (compatible with: debug)```


I think I understand this now,
The GMM would need to explicitly declare different capabilities such that A-release depends on B-release. Since this only specifies different attributes, which does not mean they are incompatible. Hence gradle still chooses the debug variants for other dependencies .

It chooses the debug variant because the debug variant is what is requested by the configuration

would the variant selected for transitive dependencies depend on what was requested by the  configuration or the variant compatible with the variant of the specified dependency?

To get this working the way I expected it to.
i.e. have release variants depend explicitly on other release variants and similarly for debug, I had to update the dependencies in `A` to segregate the release and debug dependencies explicitly by specifying the buildType attributes.
This added an additional filter of the buildTypeAttr in the dependencies block of GMM for that variant.

This then leads to my expected behaviour of only changing  the variant for `A` to also change those for the transitive dependencies.

Pretty much what you’ve been saying all along that the GMM defined that `A`  depends on `C` and not that A-release depends on C-release.

&gt;  That's not correct, you can set attributes for specific dependencies like I showed him. This overrides the attributes set on the configuration.
Ah yes I misread. I thought it was on `debugImpl` rather than on the dependency. I'm really curious how that behaves for the transitive dependencies? It seems like it'd still have to use the attributes defined on the configuration because these transitive dependencies can be present in other part of the graph, so that could lead to weird results

doing `configurations.all` works but it will apply on many, many more `Configuration` objects than needed and use extra memory. If you can do it only on the compile/runtime classpath configurations of the variant that interest you, that would be better.

&gt; would the variant selected for transitive dependencies depend on what was requested by the configuration or the variant compatible with the variant of the specified dependency? (edited)
When using attributes on `Configuration` Gradle will resolve each nodes with the attributes of the consuming configuration. What the parent nodes do in their own resolution has no impact (so if a &gt; b &gt; c and somehow b select a different variant for c, it won't matter when a makes its selection of c)

Again not sure what happens if we add attributes on a specific dependency.

So if I were to add attributes to the specific dependencies too, then dependency resolution fails if there are multiple variants requested in a configuration.
Yes I’d used `configurations.all` temporarily.  will change this to only apply to the specific configurations

This  makes me think that I should specify an attribute selector for deps that I’d want to be accessible transitively?
If I do not explicitly specify specify variants , then it is possible that the variant of my direct dependency would be incompatible with the the transitive deps whose variant is defined by the configuration and not what I specified in my dependencies.

The typical case is, that the configuration defines the attributes, because you typically want all code in debug variant or all code in release variant. And (I don't know about Android but in other projects) you typically do not resolve the configurations you declare the dependencies on.
For example you have a non-resolvable configuration `deps` where you declare the dependency on A, and then two resolvable configurations `releaseClasspath` and `debugClasspath` which do not get dependencies declared directly but extend from `deps`. Those configurations then define that they want the `debug` or the `release` variant of all the libs.

I suppose it looks at `metadata/versioning/release` in the `maven-metadata.xml` for the groupId/artifactId, so if it doesn't do what you expect, I'd first check the content of that file.

That specifies the correct version, but seems to be ignored.
For reference, here's the artifact I'm trying to get: &lt;<https://maven.martmists.com/#/releases/io/github/gunpowder/gunpowder>&gt;
And I've got a dependency resolution rule to reject versions with an incorrect version *after* the +, leaving gradle to find the most recent version *before* the +

Please show your rule and dependency declaration

This code comes from a gradle plugin, hence why I'm using `add` in dependencies:
```        configurations.all {
            resolutionStrategy {
                componentSelection {
                    all {
                        if (candidate.group == "io.github.gunpowder" &amp;&amp; candidate.module == "gunpowder") {
                            val parts = candidate.version.split("+")
                            if (parts.last() != ext.minecraftVersion) {
                                reject("Version should match minecraft version ${ext.minecraftVersion}, got ${candidate.version}")
                            }
                        }
                    }
                }
            }
        }```
```dependencies {
    add("modApi", "io.github.gunpowder:gunpowder:latest.release")
}```
If I add a `println(candidate.version)` line before the version.split, it always says `2.0.0+1.18.2`

I think the issue comes from gradle attempting the entries in `metadata &gt; versioning &gt; versions` in order, assuming the first entry is the most recent one, but I don't have enough knowledge of gradle to know whether this is true or not

It is not, the docs explain how the versions are compared and ordered

I think I've more or less figured it out; `latest.release` or `maven-metadata.xml` seems to be cached, so even when a new version is published it doesn't seem to pull it in unless I wipe ~/.gradle/caches

Yes, for 24 hours by default iirc
That is configurable though

And you can use `--refresh-dependencies` to force a refresh

Is there a property for gradle.properties to permanently disable that behavior per-project?

Only if you define one, you can disable it by code as documented

Btw. I'd prefer `withModule` in `componentSelection` instead of `all` and then checking the coordinates manually.

Where exactly are all these things documented? You've mentioned that a couple of times but I've been unable to find this information on the gradle docs

In this case <https://docs.gradle.org/current/userguide/userguide_single.html#sec:controlling-dynamic-version-caching|https://docs.gradle.org/current/userguide/userguide_single.html#sec:controlling-dynamic-version-caching>

As this happens in build.gradle.kts, I'm assuming it only applies to dependencies. What if I also wanted to disable the version cache for plugins?

Same I think, you just have to call it on the right configurations, for example in the `buildscript` block.

But you should really think twice before doing such things, it will allow down your builds as any dynamic versions needs to be rechecked online on each build.

Besides that I'm not a fan of dynamic versions anyway. :-D

Hi, we’re trying to use hash versioning for each modules. For now our options is either hashing the files inside the modules or get a hash from git.

But both approaches did not consider transitive dependencies at all.

One solution that we can think of is to evaluate module dependencies and include it in hash computation

Is there other approach that we can explore? Thanks

I've managed to pin it down to this working for exclusions:

```dependencies {
  someConfig('com.example:artifact:1.0') {
    exclude group: 'com.example.exclude', module: 'excludeArtifact'
  }
}```
However if I first declare the dependency  _then_ add the exclusion later it does not work. For example:

```dependencies {
  someConfig('com.example:artifact:1.0')
}

configurations.all {
      exclude group: 'com.example.exclude', module: 'excludeArtifact'
}```


These rules are visible on the configuration itself, so in order to access them you need to call `Configuration#getExcludeRules`

I want to try this, but it seems I can’t find `1.10.1-SNAPSHOT`

```- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Plugin Repositories (could not resolve plugin artifact 'com.autonomousapps.dependency-analysis:com.autonomousapps.dependency-analysis.gradle.plugin:1.10.1-SNAPSHOT')
  Searched in the following repositories:
    Gradle Central Plugin Repository
    MavenRepo```

it's in the sonatype snapshots repo. my github has a wiki that explains how to get it

Hey <@UES7RHBDZ> I test it with one of our module, got couple of errors

1.
```java.lang.NoSuchMethodError: 'void org.jetbrains.kotlin.daemon.common.IncrementalCompilationOptions.&lt;init&gt;```
This is happening on both kapt and compile tasks. We currently use Kotlin 1.5.32

2.
```line 19:27 extraneous input '(' expecting {'}', ID}
Can't fix dependencies for ':utils'
com.autonomousapps.exception.BuildScriptParseException: 1: extraneous input '(' expecting {'}', ID}```
If this pointing to `build.gradle` parsing, line 19 is plain old `implementation fileTree(dir: 'libs', include: ['*.jar'])`

For 2, the latest snapshot (which it appears you're using) bails out if it comes across a formulation it doesn't understand how to parse. I need to suppress the stacktraces, though; they can just be warnings. That said, I appreciate the heads-up. If you add that information to <https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin/pull/749>, it makes it much more likely I'll remember to fix it :slightly_smiling_face:

For the first one, without digging in, it does seem likely it's some kind of binary incompatibility between Kotlin versions. My plugin currently uses Kotlin 1.6, the same version used by Gradle 7.5. I thought it set the api level to 1.4, though.

I'm trying to transform a `.aar` into another `.aar` (with additional attributes) but feels like the new attribute is ignored

I'm guessing because if the incoming artifact doesn't say anything about the new attribute it's considered a match? Does that make any sense?

A missing attribute is indeed always considered compatible with a requested one.
What we do in the Gradle build is make sure to set the attribute based on the extension.
See <https://github.com/gradle/gradle/blob/65e75c38bb905aaf052b083995fcfc4948e789c4/build-logic/basics/src/main/kotlin/gradlebuild.minify.gradle.kts#L54-L56>

Thanks ! This is what I <https://github.com/apollographql/apollo-kotlin/blob/6543fc9be842e7dbe3934cd96daf13816f36273c/benchmark/microbenchmark/build.gradle.kts#L20|ended up doing>. Feels a bit weird that `"jar"` artifact type was automatically created by the java plugin but `"aar"` was not created by the Android plugin. I guess that's an issue for AGP. Thanks for following up!

Try the same block in the buildscript block. And you can just use classpath configuration there

I discovered <https://youtrack.jetbrains.com/issue/KT-52966/Cannot-choose-between-the-following-variants-of-orgjetbrainskotlinkotlin-gradle-plugin170>

Alternatively, is there a way to listen when Gradle try to download a dependency?

This is unfortunately hidden and undocumented. :cry:

Maybe the Gradle team would like to document these settings in the public documentation. :wink:

See <https://github.com/gradle/gradle/issues/4629#issuecomment-1174938250> and <https://quotidian-ennui.github.io/blog/2020/06/05/gradle-timeout-fun/> for the respective settings.
```# Set the socket timeout to 5 minutes
systemProp.org.gradle.internal.http.connectionTimeout=120000
systemProp.org.gradle.internal.http.socketTimeout=120000

# the number of retries (initial included) (default 3)
systemProp.org.gradle.internal.repository.max.tentative=10

# the initial time before retrying, in milliseconds (default 125)
systemProp.org.gradle.internal.repository.initial.backoff=500```

Link to the Gradle code:
<https://github.com/gradle/gradle/blob/v7.5.0/subprojects/resources-http/src/main/java/org/gradle/internal/resource/transport/http/JavaSystemPropertiesHttpTimeoutSettings.java#L28-L32|https://github.com/gradle/gradle/blob/v7.5.0/subprojects/resources-http/src/main/j[…]rce/transport/http/JavaSystemPropertiesHttpTimeoutSettings.java>

Thank you so much <@U01QHF1A6HJ>
Will check out the links :+1:

I'd say it is very unlikely that Gradle will officially document *internal* properties. ;-)

<@URQ797WRW> I'm wondering why they _were made_ internal. They were public before. :wink:
<https://docs.gradle.org/4.3/release-notes.html#timeouts-for-http/https-requests>

What makes your think they were?
Those release notes just say that there was no timeout at all and Gradle now sets timeouts.

<https://github.com/gradle/gradle/issues/3370>
&gt; Also, the timeout property should be prefixed with `org.gradle.internal`. It is only there for testing and not meant to be user-editable.
I'm questioning this decision.