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

Gradle Community

I'm using Kotlin DSL, so I also had to add `&lt;trust file="kotlin-.*[.]pom" regex="true"/&gt;`. This is OK for me as it's only `.pom` files. You could do the same for Groovy (assuming IDEA wants them for the Groovy DSL), but beware not to introduce _holes_ in your verification (e.g. try not to blindly trust a `.jar`)

All my build files are `.kts`. I have no idea where `groovy-ant` is coming from.

Gradle would throw this error.
```Could not HEAD '<https://myinstance.jfrog.io/artifactory/gradle-releases/org/codehaus/groovy/groovy-all/3.0.7/groovy-all-3.0.7.jar>'. Received status code 403 from server: Forbidden```
Seems like gradle expects there to be a jar.

<https://github.com/gradle/gradle/issues/4107>

<https://docs.gradle.org/7.4-rc-2/release-notes.html#promoted>

No, please open an issue, especially if you have a reproducer

yep, managed to reproduce it <https://github.com/gradle/gradle/issues/19852>

sorry in advance that it's not a smallest possible reproducer and rather our working project
let me know if something is not clear
Project misconfiguration might be an issue, but it worked in 7.3.x , that's for sure

I'm confused that ever worked. I honestly thought you could not do that without an init script

This was introduced with the `pluginManagement { includeBuild(...) }` in Gradle 7. It was one of the goals that you could move everything from settings into a local settings plugin (except for including the _settings-plugin-build_ and applying your _settings plugin_).
I am surprised that there is no test case for this in Gradle’s integration test suite for this. :disappointed: (I might be the one who missed to add it…. :grimacing:)

hm, then maybe the error I saw in the past was from trying to entirely replace pluginManagement with a settings plugin from an included build? It's interesting that you can have
```pluginManagement { includeBuild(/* build that contributes directly to pluginManagement */) }```

Yes that is tricky, but it is explicitly supported. This was the attempt to dogfood it in the Gradle build itself. And that part is working (this was never merged due to other issues):
<https://github.com/gradle/gradle/blob/jjohannes/idiomatic/gradlebuild/split/build-logic/build-logic-base/settings-plugin/src/main/kotlin/gradlebuild.repositories.settings.gradle.kts#L22-L32|https://github.com/gradle/gradle/blob/jjohannes/idiomatic/gradlebuild/split/build-[…]in/src/main/kotlin/gradlebuild.repositories.settings.gradle.kts>

when they fix this regression, and I start using it, a lot of folks are going to be really happy to see dozens of lines of pluginManagement vanish across our many builds in this large repo

i want to know what is my best strategy regarding this issue?

isn't it a blocker like 7.4.1 worthy?
should we wait till 7.5?
or it could be a longlasting issue and i should rewrote all my configuration to be duplicated again?

It is 7.4.1 worthy, we are working on it.

this is confirmed in a build scan: <https://scans.gradle.com/s/4ves35brrckay/performance/dependency-resolution?toggled=dependency-resolution-configuration-gradle-initiated#dependency-resolution-configuration-gradle-initiated-0>

of course my plugin needs to support older Gradle versions, but if there's a way to make it work properly in 7.4...

since I'm not seeing anything related in the release notes I'm wondering

I think this is the relevant section <https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:requirements>?
&gt; Referencing dependency resolution results is also disallowed (e.g. `ArtifactResolutionQuery`, `ResolvedArtifact`, `ArtifactResult` etc…​). For example, if you reference some `ResolvedComponentResult` instances, you should instead declare a `Provider&lt;ResolvedComponentResult&gt;` as an input to your task. Such a provider can be obtained by invoking `ResolutionResult.getRootComponent()`. In the same vein, if you reference some `ResolvedArtifactResult` instances, you should instead use `ArtifactCollection.getResolvedArtifacts()` that returns a `Provider&lt;Set&lt;ResolvedArtifactResult&gt;&gt;` that can be mapped as an input to your task. The rule of thumb is that tasks must not reference _resolved_ results, but lazy specifications instead, in order to do the dependency resolution at execution time.

Here a demo project how to use it in configuration cache compatible way:
<https://github.com/adammurdoch/dependency-graph-as-task-inputs>

ah dang, it's a new method which returns a `Provider`: `getResolvedArtifacts()`. Makes it harder to upgrade.

I should be able to deal with that, will take a bit longer :)

Looks like this is not mentioned in the release notes or in any GH issue linked to the release. I was confused as well. But that’s it.
<https://gradle-community.slack.com/archives/C013WEPGQF9/p1643792700540709>

Anyway, it’s great that this is now possible.

Yes, that's where I copied the link from :slightly_smiling_face:

It is not in release notes as it still has rough edges that need polishing before making it (more) public.
7.5 should announce it :wink:

omg I ran into that same error but hadn't gotten around to reporting it yet. I thought it was a Gradle error but didn't dig into it...

For me, I had a main build and an included build in the same repo. Both the main and included build included _another_ build (the same one) from outside the repo. It triggered the "TurnOffDefaultTasks" error

in this case it doesn't like the mix of composite builds which themselves have `buildSrc`

I managed to workaround by moving everything out of `buildSrc` into composites, but with the kotlin DSL it's not fun (mostly because of the `libs` not accessible, but also because of inclusion of inclusion)

I'm shocked I don't see this at work, with a very similar setup. So far only on small sample projects where I'm testing various things

Whatever your included build defines as group and name.
You can also check using `outgoingVariants` task.

ok let me check (sry for thread, thought it was in :thinking_face: )

```buildscript {
	repositories() {
	     google()
	     mavenCentral()
	}
	dependencies {
		classpath("com.android.tools.build:gradle:${buildPlatform.versions.androidGradlePluginVersion}")
		classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:${buildPlatform.versions.kotlinVersion}")
	}
}```


```  Line 7:               classpath("com.android.tools.build:gradle:${buildPlatform.versions.androidGradlePluginVersion}")
                                                        ^ Unresolved reference: buildPlatform```

I recommend you try with 7.4. I believe in 7.0.2 that indeed was not yet supported, but it should be with 7.4 (I believe it also works with 7.3.3).

Indeed it works from 7.2 on.
But I'd recommend not using the legacy approach to add plugins to the buildscript class path anyway, but using the `plugins` block instead.

There you can then also use a `plugins` entry from the version catalog if your Gradle version is recent enough

first, main sources of `web` are built, as they have no dependencies
then, main source of `test` are built, because `:web` dependency can be already satsified
then, `web`’s test sources are built, because `:test` is now built too

Even though it is one project, you can have multiple sourcesets (`main` and `test`) which each have their separate classpaths:
web.main: web.main
test.main: test.main + web.main
web.test: web.test + test.main + web.main

Thus technically you have no circular dependency, although I personally have a check to prevent these kind of dependencies.

Go ahead and open an issue.
IMO it makes sense to have that support for all core Gradle plugins where it is applicable and then have higher level APIs that would help plugin authors provide the same for their use cases.

the included build does not inherit the version catalog, it is its own build

you could explicitly load the parent's libs.versions.toml with
```dependencyResolutionManagement {
     versionCatalogs {
        create("libs") {
            from(files("../gradle/libs.versions.toml"))
        }
    }
}```
but that won't pick anything added to the catalog via root settings.gradle, for example

Thanks. I completely forgot, that included build has own settings.gradle.kts, but I would anyway expecting that just adding
```enableFeaturePreview("VERSION_CATALOGS")```
there would be enough. But no there must be code as you sent.

It is an independent build that is just run as sub-build.
Why should it inherit the version catalog?
It also does not inherit other things like `gradle.properties` values and so on.

Btw. if you can upgrade to 7.4, then version catalogs are now a stable feature and do not need the feature preview anymore :slightly_smiling_face:

Yes. It makes sense that it is independent build and has event own settings.xml. But what doesn't make sense to me why it not loading by default "../gradle/libs.versions.toml".  It searching for some other location? It is not file that belong to any specific module, like gradle.properties. According path it is general location and I think that everything should use it. Purpose of version catalog is avoid dependency version duplication.  So why to not use the same toml file?

it will use its own `included/gradle/libs.versions.toml` if available

aside from dependency substitution and gradle version, an included build basically is a completely independent build

So probably also `verification-metadata.xml` which can be in `gradle` folder will be used  for included build from this `included/gradle/` folder, right?

and sure, `libs.versions.toml` IS specific to one module the same way `gradle.properties` is

You can though publish the version catalog, or make it a separate build that you can then include from both, the main project and the included build

If for example the included build is really a stand-alone project that is just used as composite here too

You can have gradle.properties in root, then is shared by all project, or have it inside module, than it is used only by one module. But libs.versions.toml is definitely not specific to some module, since in is inside of gradle folder, it is common for all modules inside of project, included module is only exeception here.

included builds are not like subprojects, but rather more similar to binary dependencies that happen to be built from source on demand

&gt; If for example the included build is really a stand-alone project that is just used as composite here too
And yes, you have right that make sense that it looking to gradle folder inside of included build, since it can be completely different project. It make fully sense from this point of view.

&gt; or have it inside module, than it is used only by one module.
If by "module" you mean "build", then this is correct.
If by "module" you mean a project within a multi-project build, then this is not correct.
You can have at most one `gradle.properties` and that must be in the root directory (not talking abou the user-specific local one in `GRADLE_USER_HOME` here)
All projects in the build (not in included builds) share that `gradle.properties` file.

&gt; But libs.versions.toml is definitely not specific to some module, since in is inside of gradle folder, it is common for all modules inside of project, included module is only exeception here.
From this I guess you indeed mean "project" when you say "module".
So assuming you remembered wrongly about having project-specific Gradle properties file,
do you still think it is different between `gradle.properties` and `libs.versions.toml`?

For me it is the same for both as both behave the same and have the same scope.
Except that you can easily import the toml to another build if you like to.

producer.pom

producer_gradle.pom

Do you mean you have dependencies declared in the parent pom that are missing now?
Gradle does not follow that concept of parent/child POMs and does not really support it.

And while you could manipulate the POM to have the parent set, you shouldn't, especially as for example a Gradle consumer would use the improved Gradle Module Metadata instead of the POM and then also miss those dependencies. So you would also need to disable the Gradle Module Metadata, ...

Try to upgrade to 7.4, a bug related to this has been fixed

Yep, search for `Plugins can be declared with a version in a subproject in more cases` in <https://docs.gradle.org/7.4/release-notes.html>

<@UABCKNV3K> is it planned to support plugin aliases without version? An use case can be precompiled plugins which aren't in `buildSrc` so there aren't accessors

For consistency too, dependencies can be defined without version

I don’t know. <@UAFD2T2QG> or <@U02HDQU88KD> may know

fwiw, we didn't consider this because precompiled plugins only have an id. The alias makes more sense when you have both an id and a version. Otherwise, you might end up with more letters in `alias(libs.plugins.precompiled)` than `id 'precompiled'`).

Yes, there is an issue for this, but I do not know when or if we will implement it for sure: <https://github.com/gradle/gradle/issues/17968|https://github.com/gradle/gradle/issues/17968>

I think this thread should help: <https://discuss.gradle.org/t/7-3-test-suite-inherit-test-libraries-for-integration-test/41980/9>

Thanks for the link, interesting read. As for the final post in the thread, seems quite complicated, and can’t directly copy as my project is still on Groovy DSL. Any ideas on whether this is just an oversight or by design?

I don't like the final post tbh.
"oversight or by design" should be clear from the thread, shouldn't it?

Yes sorry, just read the post before in more detail where extends are setup for main `test` suite only. However, I think your reply in this thread is essentially what I tried in my second code block?

Not really.
You extend `implementation` so you inherit all dependencies declared on `implementation` which does not include the project classes.
In my post in that thread it extends `testImplementation` which has a dependency on the project classes and thus you inherit this dependency too.
But doing that is not idiomatic as I interpret the answers of the Gradle guys. :-)

Aha makes sense, will give it a try, thanks :thumbsup:

That did the trick, at least compiling now. Appreciate it may not be idiomatic, but it’s progress. Cheers <@URQ797WRW>

You need to use the type-unsafe API: <https://docs.gradle.org/current/userguide/platforms.html#sub:type-unsafe-access-to-catalog>

You can it only use like that with a hack-around.
Alternatively you could use the type-unsafe string-based API to access the catalog.
See here for more information including my hack-around: <https://github.com/gradle/gradle/issues/15383>
For the stringly api, get the `VersionCatalogsExtension` extension and use that.
<https://docs.gradle.org/current/userguide/platforms.html#sub:type-unsafe-access-to-catalog>

I think the hack-around only works for precompiled script plugins, of which `buildSrc/src/main/kotlin/DoSomethingWithVersions.kt` would not be one

Thanks guys. If I try to dig into it, do you think a newbie like me could create a PR to fix it or it needs a lot of changes so not anytime soon it's happening?

If you're asking specifically about precompiled script plugins, I think it is not a newbie-friendly change, as mentioned in the issue it really needs some design work put into it, not just making code changes.

Your specific question, which is for what we call "binary" plugins, is something that I don't think is really ever going to be fixed. Binary plugins have never had generated accessors available, and I don't think there's plans to change that.

&gt; I think the hack-around only works for precompiled script plugins
I think it should work alike in a normal Kotlin file, as long as you have access to the `project` to get the `LibrariesForLibs` extension or supply it in.

Thanks everyone :slightly_smiling_face: you gave me good points to start.

I doubt anyone is working on that, but I think it would be misleading, since it's the project _path_ which is used in type safe accessors. So you'd have a mix of projects under the same "node" which could come either from a path _or_ a project name, which would IMO be confusing.

This is defined at <https://docs.gradle.org/current/userguide/platforms.html#sub:mapping-aliases-to-accessors>, it would be nice to have in the Javadocs as well though. Feel free to submit a PR adding it to all of the getters.

Thanks, I'll create a PR to add it to javadoc, quite useful info

<https://github.com/gradle/gradle/pull/20077>

That's indeed useful to have in the javadocs, sorry about not doing this in the 1st place!

Easy to miss and easy to correct. No harm done ,)

I think it is the same problem as with usage of libs  in buildSrc

but I am not using plugin aliases inside `buildSrc`, I am adding the plugins as dependencies in `buildSrc/build.gradle.kts`, so they are added to the classpath, then later, in a normal project, I try to do `alias(libs.plugins.whatever)` and it doesn't work.

I would expect this to work in 7.4

Personally I would prefer to lift the need of adding a version there like in a normal dependency inside `[libraries]` , because so, you can define aliases for your plugins inside included builds that are not generating accessors (not `buildSrc`).

<@UAFGSU86M> when you created this feature what was the reason to force the version?

See <https://github.com/gradle/gradle/issues/20084> and the linked issue.
We have not found a satisfying API for this but decided it was not blocking for marking the feature as stable

We use the BuildCache, even for the Android UI Tests, and we decided it's good enough

I have own scripts. It is huge difference if you run all test (60+ min) and only changed files (few seconds)

<@UV12V183E> you have your own scripts to do what?

<@UD13D3DSR> are you talking about gradle's remote build cache?

<@U02371L7SLF> To find modified files and run tests for them instead of running all tests. It is almost same as AffectedModuleDetector. I didn’t know that plugin like this exists…

and <@UV12V183E> are you using the gradle build cache in addition? We already use remote build cache so I'm specifically wondering if I'll expect to see value in using both cache and this plugin together

<@U02371L7SLF> No. I experimented with remote cache but I always use clean builds

BuildCache is confiable. Detecting affected tests requires instrumenting and it's a complex thing that could be error prone.

Even if done right, the benefits are bigger the less you modularize, and to our use case has a disadvantage: I want to have the full report to compare coverage between commits, if I don't run some tests I can't recalculate how it changed.

So, that's why I didn't invest on that. I understand there may be scenarios where it's worth.

Hmm… does an `ArtifactView` with a suitable component filter achieve this?

I just discovered component filter! checking now

it feels like it could… but I’ve never tried it

There is a really evil way of doing it… if that doesn’t work…

I think this works
```it.componentFilter { componentIdentifier -&gt;
  componentIdentifier is ModuleComponentIdentifier
}```

<https://docs.gradle.org/current/userguide/dependency_locking.html#lock_all_configurations_in_one_build_execution> ignoring the dependency locking bit, does that help?

interesting. We don't use dependency locking yet (though we should)

all you people using dependency locking before you started worrying about `failOnVersionConflict()`… :stuck_out_tongue:

I wanted to get us using platforms consistently first, because we have so many version conflicts across the build

I’m kidding… although my experience says this is a huge issue in open source projects… most cases are probably harmless… but people are stupidly slapdash about it.

build_gradle_kts.kt

I've started using this (well, a a bit complex in real usage but you get the gist) to define a platform based on the contents of a version catalog. seems to work pretty easily

that presupposes we're already using version catalogs &lt;&lt;

(but yes, it's a neat approach) :bookmark:

I happen to be doing exactly this today, trying to pre-populate the dependency cache on a docker image for ephemeral builds. Care to share your final solution? I’m about halfway there, got things resolving for specific configurations, now working on resolving all resolvable configurations…

eh, here's the whole thing. You can simplify it dramatically by deleting the android-specific stuff <https://gist.github.com/autonomousapps/f0133e58a612b6837f3f4f6554337035>

note that this only resolves the compileClasspath, not, say, testCompileClasspath

Thanks for sharing! That helps immensely.

```val artifacts = configurations
  .getByName("compileClasspath")
  .artifactsFor("jar")
tasks.register&lt;ResolveDependenciesTask&gt;("resolveDependencies") {
  setCompileClasspath(artifacts)
}```
where `artifactsFor()` is defined as:
```private fun Configuration.artifactsFor(attrValue: String): ArtifactCollection = incoming
  .artifactViewFor(attrValue)
  .artifacts

private fun ResolvableDependencies.artifactViewFor(attrValue: String): ArtifactView = artifactView {
  it.attributes.attribute(attributeKey, attrValue)
  it.lenient(true)
  it.componentFilter { componentIdentifier -&gt;
    componentIdentifier is ModuleComponentIdentifier
  }
}```
note this is necessary because I'm dealing with an Android project

simply configuring that task resolves dependencies (by gradle)

I suppose this is because you're calling `.artifacts` on your artifact view at configuration time. How about doing that in a provider you pass to `setCompileClasspath` instead? (such that it's only resolved at execution time)

If I use `provider { artifactView.artifacts.artifactFiles }`, I still see this, which does look like it's resolving the dependencies at configuration time. What am I missing?

no matter what I try, it really wants to resolve these dependencies during configuration :disappointed:

I remember seeing that with transforms (agp + AndroidX), but I haven't for dependencies that I can remember

I did `mv ~/.gradle/caches/modules-2/ ~/.gradle/caches/modules-2-backup` and then ran a build. So you could try it yourself :slightly_smiling_face:

Dependency resolution is capable of working in parallel even during configuration time.

The problem with either optional or provided is that it won't be in the compile classpath and users would have to add it explicitly.
Compare that to the current situation where things Just Work™, you might have some JAR at runtime that didn't expect, and you could re-declare the dependency as provided or optional to get rid of it, or use some sort of filtering when assembling your _distribution_ (e.g. WAR file).
Generally, compileOnlyApi are annotations that are needed by annotation processors or other static analysis tools, so they're harmless on the runtime classpath, but would break builds if absent from the compile classpath.

It's been like that since I started using Gradle, but ai thought it was a limitation on the pom.xml

<@UD13D3DSR> you are not using Gradle longer than 6.7? I thought I've seen you around here earlier

I started with Gradle when Android did... Gradle 3?

Ah, ok, just wondered.
Because `compileOnlyApi` was introduced with 6.7 :slightly_smiling_face:

the problem is that putting it with scope `compile` is totally unexpected for me, since it _must not_ appear at runtime

Well, another of those shortcomings of the POM model I guess and Gradle guys had to make a decision how to map it.

yes but my question is whether it's intentional or not, since the current mapping is the default

I can only guess of course, but according to the 6.7 release notes, the intention of it is to combine compileOnly i. e. only available at compile time with api i. e. available to consumer.
So for the POM model, the nearest is to put it in the `compile` scope, as it is then available at compile time of the consumer.
The alternative would be to have it e. g. `optional` which then would mean it is not available to the consumer.
In most cases a superfluous dependency at runtime does not hurt, but a missing dependency at compile time makes compilation fail.
So to me this mapping the POM makes the closest sense given the limited possibilities.
So my plain gut-feeling guess is yes, it is intentional. :slightly_smiling_face:

in my case the superfluous dependency is hurting a lot

because it's bringing a load of unwanted dependencies transitively (the whole Micronaut runtime)

I guess that's a case for manual POM manipulation using `withXml` then.

Just as info: Technically, the problem is not `compileOnlyApi`  but the general way how dependencies that end up only in the `apiElements` variant (and not the `runtimeElements`) are mapped. That was introduced long before 6.7 (5.x something I guess). compileOnlyApi was only added as convenience in 6.7 (you could easily add that yourself in earlier Gradle version).
I guess Gradle could introduce something in the pom mapping tom make this configurable when you configure the component. I think there is no universal “right way” to do it. POM is just too limited :confused:

Indeed. A similar problem happens with test fixtures dependencies, which are rightfully published as "optional" because test fixtures are implemented as feature variants. However in practice, it's not clear that you actually want that to appear in the generated pom.

Mh… yes from that perspective it would probably be more consistent if things that are only in “apiElements” would be marked as “optional” as well (if in doubt, publish less information in the POM…).
But I guess we did not think about this case back then :slightly_smiling_face:

the world would be a better place without pom.xml :slightly_smiling_face:

Oh this really is a missing feature it looks like. :disappointed: You could use Ivy publications instead I guess. If you only use Gradle (and with that the Gradle Metadata) it effectively makes no difference if you use Ivy or Maven…

Maybe you know this already, but you can write a component metadata rule to infer the `status` attribute from the version at resolution time. E.g. a rule like that:

```@CacheableRule
abstract class ComponentStatusRule : ComponentMetadataRule {
    override fun execute(context: ComponentMetadataContext) {
        val version = context.details.id.version
        val lcVersion = version.toLowerCase()
        if (lcVersion.contains("alpha")
            || lcVersion.contains("-b")
            || lcVersion.contains("beta")
            || lcVersion.contains("cr")
            || lcVersion.contains("m")
            || lcVersion.contains("rc")) {

            context.details.status = "integration"
        }
    }
}```
```dependencies.components {
    all&lt;ComponentStatusRule&gt;()
}```
Of course all the projects in your organisation then needs to use this rule…..
On the upside you also get the “right” status for the external libraries that are published on _Maven Central._

interesting, thank you <@U023HSZL88M> - will play around with that a bit

Here are the related docs: <https://docs.gradle.org/current/userguide/component_metadata_rules.html#sec:custom_status_scheme>
(Although it does not give the example with the version number, which is probably the most useful application of such a rule)

That's not strange but expected.
`dependencyResolutionManagement.repositories` is for production dependencies, not for plugins and their dependencies.
And besides that, `pluginManagement { ... }` is evaluated separately from the remaining script first, as it could for example add a settings plugin using `includeBuild`, that then can be applied outside the block.
Define your repository in `pluginManagement.repositories` and it should probably work, as that is the place to define repositories for plugins and their dependencies.

`pluginManagement.repositories` also has the same repositories:
```pluginManagement {
    repositories {
        gradlePluginPortal()
        mavenLocal()
        mavenCentral()
    }
}```

It looks I found a reason. It’s a chicken and egg problem.

Root project uses included build to modify his own repositories.
Included build resolves dependency before this happens.

Workaround to illustrate the issue:
```pluginManagement {
    repositories { // FIX is here: they are used to build build-logic-settings
        gradlePluginPortal()
        mavenLocal()
        mavenCentral()
    }
    includeBuild("build-logic-settings")
    includeBuild("build-logic")
}
// plugins from build-logic-settings modifies pluginManagement in this project 
plugins {
    id("convention-plugins")
    id("convention-dependencies")
    id("convention-enterprise")
    id("convention-cache")
}```

Of course, as I said, the `pluginManagement` block is executed separately from the remaining script as it can for example contribute settings plugins to be applied in the same script.

Just basic locking for a single configuration.

Maybe dependency verification is more what you'd like?

Maybe that's a better name for it?

I just seen a lot of real world situations where versions get bumped some people don't realize it. This would give visibility into that and check into source control this baseline file. I created a Gradle plugin that does this for modules and artifacts and dependency trees.

<https://github.com/Kotlin/binary-compatibility-validator|https://github.com/Kotlin/binary-compatibility-validator>

Library inspired me with the ability to create a baseline and check against it.

The goal of that library is to prevent public API changes

I haven't published the work I've done probably yet. But will if it's a value.

I just talked to <@UMD8Q0MBL> about it. Potentially could leverage the lock file format, but still provide the functionality I've described.

No, not a better name. A different Gradle feature. You have a metadata file where you have the checksums for all dependencies. If a checksums is not correct, you get an error. This is to prevent corrupted or infected dependencies. But you also get a clear complaint if a checksum is not present, which is exactly the part you want I think.

I made a more complete description of the functionality I'm looking for here: <https://gradle-community.slack.com/archives/CAH4ZP3GX/p1648518134919579>

I still think that the dependency verification feature would be sufficient for your needs and additionally protect against corrupt or infected libs.

That would definitely be helpful.  While protecting against correct or infected libs is very critical, this use case is more just surfacing version changes, additions and removals.

So, when I bump Kotlin from 1.5.31 -&gt; 1.6.10, it tells me:
- org.jetbrains.kotlin:kotlin-stdlib:1.5.31
+ org.jetbrains.kotlin:kotlin-stdlib:1.6.10

Then I would need to re-baseline in order to accept that change, otherwise the build fails.

Goal: Make any changes to resolved dependencies caught, have a developer choose to accept/baseline it, and then have a history in Git via the tracking file.

Yes, and all that and more you get with dependency verification. How often do I have to repeat that?

Or well, you wouldn't see removals. But changes and additions as for those no checksum would be present in the versioned file and thus the build would fail.

Don't get me wrong.
If you want to reinvent the wheel in your own plugin, be welcome to do so.
You just asked whether the functionality is there already and seem to forcibly refuse to listen to the answer.

A lot of this is new to me, so I didn't realize you were referring to an existing feature of "<https://docs.gradle.org/current/userguide/dependency_verification.html#sub:enabling-verification|dependency verification>".

Thank you so much for your answers. I'm sorry I've been unable to understand yet.  I'll try out dependency verification and see if I can create the behavior you have called out.

Again, thank you.  Sorry, I am blindly learning all this, and honestly been a bit stubborn, so I apologize for that.

"changing versions" means `-SNAPSHOT` , I think it's possible for other ones to be "changing" but that's the only example I know of.

ref. <https://docs.gradle.org/current/userguide/dynamic_versions.html#sub:declaring_dependency_with_changing_version>

basically, if you have `implementation("my.dep:artifact:1.0-SNAPSHOT")`, `failOnChangingVersions()` will cause an error

Thanks for the clarity <@U02HDQU88KD>!  That's unexpected, but makes sense.

Okay, I added a `-SNAPSHOT` dependency and now see (screenshot).  Which confirms what you said.

Is there a verify task or something I can run that will fail?  This `module:dependencies` task succeeds, even though it says "FAILURE" when trying to resolve.

that is intentional, as the dependencies task wouldn't be able to print its output otherwise. you can make your own task to resolve all configurations if you want, but I don't think there's anything built-in. I usually use `assemble` or even just `compileJava` as my "cheap" task to do resolution, as if the resolution fails it's the same as if you made a dedicated task.

That's the thing, that `assemble` succeeds fine, even with this.  But... I am not relying on any classes from that module.

Okay, thank you for your answers!

I think that means the the plugin I have made has a real purpose!  Which is good since I spent a week on it.

We're doing something quite similar (in about 70 lines of groovy DSL which I sadly cannot share), but only for specific configurations and with filenames that can easily be filtered, so they can get special treatment (i.e. need for approval) in a PR when changed. Also, we do not fail the build when dependencies are removed, which might be an option worth considering for your plugin as well.

Nice! That is an interesting point about removals only. I'll think about that one.

The plugin I have supports 3 formats: artifact list, module list and tree formats. For all main purposes the artifact list is most used, but for upgrades the tree one is super useful.

What do you do when they are removed then, how do you rebaseline?

Same functionality that it can be configured for only specific configurations.

Obsolete entries are usually only removed when other changes make an approval necessary, anyway. Then whoever introduced a new/updated dependency needs to run the rebaselining task in their PR branch.

That makes sense, but won't that allow a removed library back in? For example, if I pull out leak Canary and don't re-baseline and then somebody adds it back in?

In my situation I'm thinking of it as a source of Truth for resolved dependencies, similar to the way version locks work. But it doesn't actually lock the version. It just prints out the resolved versions.

This is mostly not a problem for us, since when a library is approved, it usually stays approved. If not, the remover could just manually re-run the baselining and it would be gone.

Thank you.  In this case for an Android app, the less dependencies, the smaller the app size.  Additionally, the addition or removal of a dependency can impact the behavior of the code.  So we would want to try and make any additions or removals accounted for.

Here is an example of running code after the `:dependencies` task: (see screenshot)

Ideally I would just like to execute code after all of the componentSelection is complete though. :thinking_face:

See <https://github.com/DiUS/java-faker/issues/327>

Does something like this work?
<https://discuss.gradle.org/t/remove-transitive-dependency-with-classifier-and-replace-with-new-one-without-classifier/26324/6>

You can also look how this <@U023HSZL88M>'s plugin fixes similar thing with guava <https://github.com/jjohannes/missing-metadata-guava>

I had a similar issue with `guice-noap` referenced by `typesafeconfig-guice` . This is the rule that fixes the metadata of `typesafeconfig-guice` and you could do smth similar for `javafaker` :

```/**
 * Removes the 'no_aop' classifier from the Guice dependency, because it
 * no longer exists with Guice 5.0 to which we upgrade the dependency.
 */
@CacheableRule
abstract class TypesafeConfigGuiceRule : ComponentMetadataRule {
    companion object {
        const val TYPESAFE_CONFIG_GUICE_MODULE = "com.github.racc:typesafeconfig-guice"
    }

    override fun execute(context: ComponentMetadataContext) {
        context.details.allVariants {
            withDependencies {
                removeIf { it.group == "com.google.inject" }
                add("com.google.inject:guice")
            }
        }
    }
}```

```// register rule:
dependencies.components {
    withModule&lt;TypesafeConfigGuiceRule&gt;(TypesafeConfigGuiceRule.TYPESAFE_CONFIG_GUICE_MODULE)
}```

we solved it by substituting any request for the android variant with the “normal” one:
```// javafaker requests the android variant of snakeyaml, which might not always exist
configurations {
  configureEach {
    resolutionStrategy {
      eachDependency {
        if (requested.name == "snakeyaml") {
          artifactSelection {
            selectArtifact("jar", "jar", null)
          }
        }
      }
    }
  }
}```

:point_up: That’s also a neat and compact solution for this. I might like it more than mine. :smile: Thanks for sharing <@UMG417LGH>