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

Gradle Community

we’ll need some sort of information… “it doesn’t let me build” doesn’t say much. What is `Android Resolve`? what does it mean to `delete Resolve dependencies`? what are your `Ads`? Where is my mind?

It’s an Android app, that is using Google AdMob 7.0.0 for advertising, sorry for being that violent lol

Im using Unity 2020.3.33f1 to to a .apk build and updload it to the Android PlayStore

And gradle somehow is giving me an error everytime i try to build the .apk

Same error as this people are getting here <https://answers.unity.com/questions/1711904/android-apk-build-failing-execution-failed-for-tas.html>

You’ll probably have more luck getting help from unity or android communities. This doesn’t seem related to gradle at all.

Please do not split topics across several threads.
This makes following the conversation in the threads view very hard as the context of the other messages is missing.
If you have additional information either edit the original message or post to its thread.

To unlock --tests for you proxy task, make it a proper task implementation with registered tests option. Then just grab and replicate macosArmXXX task configuration

Some docs for you <https://docs.gradle.org/current/userguide/custom_tasks.html#sec:declaring_and_using_command_line_options|https://docs.gradle.org/current/userguide/custom_tasks.html#sec:declaring_and_using_command_line_options>

mmmm but how do I link a task input to another task input ?

You don't. You recreate the task completely.

i.e. your new task will not depend on macosXXX, but instead will act as an alternative to it with replicated and extended config

Is that even possible without pulling the whole Kotlin plugin source?

Unfortunately gradle does not support extending existing tasks

Pretty sure `macosArm64Test` references a bunch of private/internal symbols so it's not just copy/paste a file

You already have the whole kotlin plugin source on your classpath

Run gradlew model to figure out task type

That's a lot of trouble to workaround the IntelliJ awkwardness :sweat_smile:

Then use ide class navigation to open it up and see which options you need to propagate and which base types you need to extend

It's really not. In the end you just proxy the config from kotlin task to your new task

I mean, I don't even know the concrete type of `macosArm64Test`

So now I can create a new `KotlinNativeHostTest` task

Now I need to find where in the Kotlin plugin this stuff is configured and copy/paste that?

That goes into `KotlinNativeTargetWithHostTestsConfigurator`

Not copy, just proxy into actual task config. That way you don't have to bother with actual values

That's the thing `KotlinNativeHostTest` input values are configured in the Kotlin plugin. The only input value I can proxy is `--tests` . All the rest I have no idea how to get

That's not what I mean. I meant this 

myCustomTask.domainProp = macosArm64Test.domainProp

Do this for all public properties

For an example, there is in KotlinNativeTest:
```val executableProperty: Property&lt;FileCollection&gt;```


myTask.executableProperty.set(kotlinTask.executableProperty)

You can even flatMap task provider to avoid configuring kotlinTask

You need to add google repository in your settings.gradle.kts

Also check that you've specified a plugin version

Can't really help more without seeing your buildfile

thanks I wanted to know how to send the compilation file but I'm very new to this, anyway I appreciate the help and I'll go after checking this.

The stack I'm getting looks like this:
```org.gradle.api.GradleScriptException: A problem occurred evaluating root project 'andr_core'.
...
Caused by: org.gradle.api.internal.plugins.PluginApplicationException: Failed to apply plugin 'org.gradle.jacoco'.
...
Caused by: org.gradle.api.UnknownDomainObjectException: Extension of type 'VersionCatalogsExtension' does not exist. Currently registered extension types: [ExtraPropertiesExtension, FulladleModuleExtension, DirectiveDataExtension, ReportingExtension]```

The convention plugin I'm applying that seems to manifest this is roughly:
```    override fun apply(project: Project) {
        if (!project.isRoot) {
            project.configurations.all {
                project.extensions.getByType(VersionCatalogsExtension::class.java)
            }
        }
    }```

The project being evaluated in the above stack is NOT the root project so there appears to be some coupling that I'm not yet aware of?

There's only one `ResolutionStrategy` per configuration and calling `resolutionStrategy()` only executes the action (or closure) on that object to configure it.

<https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/TaskOutputs.html#cacheIf>

the spec is evaluated at execution time, so use `Provider.get()` within it

What does the task do? Because if it's using a dependency declared in the file, it would rerun (e.g if you run the build with `-t`, continuous mode). If it's not, then it means that the TOML file is an input of your task. Declare it as such and you should be good to go.

Runs a python script that generates a $projectroot/gradle/pom.xml for dependabot to consume :sob:

and the idea is that any dev that edits libs.versions.toml should automatically get a diff on the pom file that they remember to commit.

I could do it in a commit hook, but commit hooks are a bit nasty to deal with :confused:

And why do you want to trick dependeabot that way?
It would not help much, would it?
At least the PRs would be pretty useless, as they would just change the pseudo POM.

Maybe it would be better if you use a proper tool like Gradle Versions plugin of Ben Manes and set up a GitHub action that runs it regularly to get notified of updated dependencies.

There is even an extension for it that can update the new found versions into the TOML

you can use Renovatebot which supports the TOML file

Because dependabot doesn't scan libs.versions.toml files, and I don't think I can post OWASP output to the github security page from the CI, and it's a pretty nice place to keep such info.

renovate only pushes to PRs, going to get noisy and ignored.

To be clear, getting pings on updates is nice, but it's the vulnerability integration that's valuable.

<https://github.com/dependabot/dependabot-core/issues/3121> any year now :disappointed:

if you're interested in security, then neither renovate nor dependabot do the job, because they don't care about resolved dependenceis

it gives a false impression of security IMHO

because they only care about what you declare. Doesn't mean that it's what is effectively used, or doesn't care about transitive dependencies

Unfortunately I don't work for the Due Dilligence company that requested it from me :slightly_smiling_face:

There is a dependency check Gradle plugin that works with the resolved dependencies and checks OWASP. But it is of course not integrated with the GitHub UI, unless you parse the result somehow and maybe use the GitHub API to upload it if possible.

<https://github.com/dependency-check/dependency-check-gradle>

Yeah, don't think that API are open as dependabot is explicitly integrated with GH, but I should have another look. Nice to save some build minutes by not having to run owasp though.

<@UAFGSU86M> yep that's what I want to replace here.

right, but it does the job _better_ than dependabot

And it is the one I meant :slightly_smiling_face:

It does its job by dumping output in the CI, and at best I can put it in a PR comment, while you are correct, it doesn't fit the goal :confused:

there's also <https://snyk.io/blog/gradle-plugin-by-snyk-gradle-dependencies-scanning/>

Yep, lots of alternatives. Just want to get the security page filled out so that I can do something useful.

<https://docs.github.com/en/rest/code-scanning>

&gt; The code scanning API lets you retrieve and update code scanning alerts from a repository. You can use the endpoints to create automated reports for the code scanning alerts in an organization or upload analysis results generated using offline code scanning tools.

Much better than polluting gradle and the git repo. Was too locked into thinking it was due to GH's dependabot partnership.

I'll see what I end up with... pretty nice to have the dependency page populated as well.

I think you can even use the CodeQL GitHub Action to do the vulnerabilities scanning and integration into the UI.

But I don't know how that works, whether it uses the resolved libs or also just the declared ones

I guess it depends on how well it knows how to extract versions for a project that uses libs.versions.toml, but other than that it doesn't support Kotlin yet - which my code base is written in, <https://github.com/github/codeql/issues/4699>

Well, any project that does need explicit support for things like version catalogs or TOML files is doing it wrong. Because they do own parsing and thus suffer from the exact problem Cédric mentioned, they check your declared versions, not your actually used versions.

which is still better than doing nothing, to be fair :slightly_smiling_face:

If a tool does it right and for example uses the tooling api to get the resolved dependencies to be checked, it automatically supports all existing and future ways to declare versions.

Agree. But it's a best effort thing. Would be nice with gradle lock files instead, but got burned by that last time I tried it out wrt how it interacted with IDEA.

Seem to recall that's somewhat related to gradle plugins not being pulled straight from maven central with proper signatures and so on? Anyways, different subject.

Ah nah... mixing it up with dependency verification. Lockfiles might have worked fine.

Anyways, thanks for your various suggestions, have a great afternoon.

Do you mean using the same catalog in buildSrc and production?

<https://docs.gradle.org/current/userguide/platforms.html#sec:importing-catalog-from-file>

Sorry if you missunderstood, I'm not asking how to use version catalogs, just what is the best practice between using version catalogs or defining a map of strings for dependencies in the `buildSrc` package (or just versions in constants)

oh, use version catalogs :slightly_smiling_face:

Do you have any explication about this ? :slightly_smiling_face:

well, the docs explain it already, but if you're looking into more design decisions, here's what I wrote back then: <https://gradle.cloud.xwiki.com/xwiki/bin/view/Main/Design%20specs/Dependency%20management/Version%20catalog/Version%20catalogs%20-%20Main%20spec/>

2 main advantages: type safe accessors, and doesn't invalidate the build when you change a version.

You are probably falling into some of the weirdness of the GradleRunner API. I don’t remember exactly all the details but when the `withEnvironmen()` API is in use, internally Gradle has to fork a Gradle daemon to ensure the environment variable are properly configured. There are two things to be mindful here: 1) make sure you configure the project directory (<https://docs.gradle.org/current/javadoc/org/gradle/testkit/runner/GradleRunner.html#withProjectDir-java.io.File->) and 2) you should always specify the working directory in your `ExecSpec`  when it is important. In this case, you wish to run `chmod` in the `projectDir` so the `ExecSpec` should be configured as such:

```tasks.register('exec', Exec) {
  commandLine 'chmod'
  workingDir projectDir
}```

Thanks Daniel! It seems withEnvironment() fully replaces the default System.getEnv(). I only need to add an extra one so I'm gonna try to combine the actual default environment with the few extra keys I need. 

The execSpec in question which is failing is an internal task managed by Gradle. The task which is failing is coming from the Application plugin. I'll take a peek and see if this task has anything I can configure or modify to get around this.

Finally got some time to test it out and it was an easy fix. Propagating the initial System.getEnv() into the map that I was adding with the .withEnvironment() method and adding my controlled key/value pairs after the fact, cleared it all up. My code was originally creating a map which contained only my controller key/value pairs.

Ah yes that is another gotcha with the Gradle Runner. A similar overwrite issue is also present with the withArgument(s) API.

`kotlin-dsl`indicates that your application is a Gradle plugin; perhaps this isn’t the case.  You can use the Kotlin DSL in your build script with the kotlin(“jvm”) (or other platforms) - but you should not mix a Gradle Kotlin DSL plugin (which requires Gradle 1.4/1.5) with other Kotlin code (that requires 1.6).

for example, here is a Kotlin 1.6 project:
```plugins {
    
    kotlin("jvm") version "1.6.20"
    `maven-publish`
    
    `java-test-fixtures`
}```

Interesting and thank you for your reply.  I have all my build scripts in buildSrc dir using the conventions method/style.  That's where the `kotlin-dsl` is set for me.

In one of my build script convention files that contains the KotlinCompile settings, I have the following:

```plugins {
    idea
    kotlin("jvm")
    kotlin("plugin.allopen")
    id("helper-conventions")
    id("kotlin-test-conventions")       
}```
No version on the jvm line in this case.  Because I'm using precompiled scripts, I can't set a version... so its coming from the `build.gradle.kts` in my `buildSrc` dir?

Hmmm.  Not that familiar with previnoiked scripts (tend to do full plugins).  This link seems to indicate there's a coupling between the build.gradle.kts and script plugins.  <https://dev.to/dussim/gradle-precompiled-script-with-kotlin-jvm-clf|https://dev.to/dussim/gradle-precompiled-script-with-kotlin-jvm-clf>

In a general sense, the authors of the Gradle plugins tries their best to give sensible error message. In this case, the Android team gives to the users a sensible error message which says “Failed to find Build Tools revision 29.0.2”. In those cases, we can’t be of more help then echo the error message which is the Build Tools version 29.0.2 wasn’t found. Meaning, you need to install the Build Tools version 29.0.2. I suggest looking at the Android documentation to find out how that can be done. It’s an environment/configuration issue not a Gradle specific issue. Given Dart language is used, you may need to refer to which ever framework you may be using that in turn use the Android Gradle plugin.

use of `project.afterEvaluate`should be avoided, as it leads to all manner of problems.

And usage of `allprojects`/`subprojects` is also discouraged as it leads to other bunch of problems

Both amazing pieces of advice, this is the way!

```tasks.register("publishAll") {
	group = "publishing"
	description = "Publish all submodules at once."
	
	dependsOn(subprojects.filter {
		it.childProjects.isEmpty()
	}.map {
		"${it.path}:buildAndPublish"
	}).finalizedBy("closeAndReleaseSonatypeStagingRepository")
}```

calling `publishToSonatype` at the root project already publish all projects to sonatype

*all projects which applies maven publish plugin

Committed a fix to this and gradle still doesn't find `publishToSonatype` during the gradle action

try to call `publishToSonatype` in GitHub directly to check if the problem persists

I get <https://github.com/Ayfri/PIXI-Kotlin/runs/6249903394|this>

then you have something wrong in your configuration

```     repository.stagingProfileId.set(
                        "${target.properties["oss.stagingProfileId"] ?: System.getenv("OSS_STAGING_PROFILE_ID")}",
                    )```

you can get that profile id from sonatype url

&gt; • `oss.stagingProfileId`: Visit <https://oss.sonatype.org/#stagingProfiles|staging profiles> select your profile from the list and copy the code after the `;`, for example, the code from this url `<https://oss.sonatype.org/#stagingProfiles;32gf35h34654>` is `32gf35h34654`
&gt; 

And where do I put this ? :slightly_smiling_face:

in the nexus repository extension
```repository.stagingProfileId.set(here)```

But using `:publishToSonatype` from my custom task `buildAndPublish` doesn't work because gradle can't find the task x_x

Oh thank you so much, it is now published :smile:

so much trouble to getting this, 5 weeks :cry:

one approach for this is to *always* have taskA depend on taskB, but disable taskB (`onlyIf`) as necessary.

the problem is `taskB` may or may not exist

I can’t disable a task that does not exist!

I guess I could have a dedicated no-op task, but that seems a bit sloppy

Can you make it always exist, but make the execution conditional?

yep! looks like a no-op task would be the way to go here, which is unfortunate

Shouldn't need to be a no-op, make the execution conditional with onlyIf

yep! either a real task or a no-op one that is `onlyIf = false`

Typically it would always be the real task, with an appropriate onlyIf to execute it when needed.

How is it defined whether taskA depends on taskB and how is it defined whether taskB exists?
If if for example is, that taskA always depends if taskB exists and taskB always exists if plugin X is applied, then use `pluginManager.withPlugin` to react to X being applied and add the dependency in there.

That's currently not a supported thing. I have discussed a similar topic with some Gradle folks recently, where I need a platform to depend on all projects of a particular kind automatically. It's one kind of "aggregation" pattern which is not well supported.

`buildscript`, `initscript`, `plugins`, and `pluginManagement` are all special blocks that extracted and run separately, before any other part of the script. this is necessary because Gradle needs to use them to set up the build environment for the rest of the script. you cannot use anything defined outside of the block, in these blocks.

How then can I define a method within the initscript?

you cannot share anything between the special blocks as they run in a separate context

i'm talking about within the initscript alone

something like

```
initscript{
    def hi() {
        println "hi"
    }
    hi()
    hi()
}```
does not work

i get the following error:

```
FAILURE: Build failed with an exception.

* Where:
Initialization script '/Users/aloneitan/.gradle/init.gradle' line: 1

* What went wrong:
Could not compile initialization script '/Users/aloneitan/.gradle/init.gradle'.
&gt; startup failed:
  initialization script '/Users/aloneitan/.gradle/init.gradle': 1: Unexpected input: '{' @ line 1, column 11.
     initscript{
               ^
  
  1 error```


I don't need to share a single method between, say `initscript` and `plugins` .

just keep it within `initiscript`

try adding a space? I'm not sure, might be a quirk of the Groovy DSL (seems to work fine for me in Kotlin)

```FAILURE: Build failed with an exception.

* Where:
Initialization script '/Users/aloneitan/.gradle/init.gradle' line: 2

* What went wrong:
Could not compile initialization script '/Users/aloneitan/.gradle/init.gradle'.
&gt; startup failed:
  initialization script '/Users/aloneitan/.gradle/init.gradle': 2: Method definition not expected here. Please define the method at an appropriate place or perhaps try using a block/Closure instead. at line: 2 column: 5. File: _BuildScript_ @ line 2, column 5.
         def hi() {
         ^
  
  1 error```


Gradle's pre-parsing is a bit of a heuristic and you shouldn't do anything out of the ordinary

Catalog completion is not supported in Groovy AFAIK.

<https://youtrack.jetbrains.com/issue/IDEA-279603/Code-completion-for-Gradle-Version-Catalogs-in-groovy-build-file|https://youtrack.jetbrains.com/issue/IDEA-279603/Code-completion-for-Gradle-Version-Catalogs-in-groovy-build-file>

Thanks for the replies! I was able to get it working: <https://youtrack.jetbrains.com/issue/IDEA-279603/Code-completion-for-Gradle-Version-Catalogs-in-groovy-build-file#focus=Comments-27-6052479.0-0>

What does it mean to “build a subproject on its own”?  Is there a minimum reproducer available?
the version catalog is semantically equivalent to directly specifying the version - no differences there.

`pluginManagement { plugin { ... } }` is simply longer available to define a default version for a plugin to be used in the build.

Version catalogs feature (doesn't matter whether used from settings script or with TOML file to define the versions) is just a newer feature that is available now and that I personally would prefer.

But either way nothing should use the "latest version in the world" unless you do something really non-standard and strange. As Chris said, you probably need to provide an MCVE to show what you mean.

Minimum reproducer:
<https://github.com/GlenKPeterson/gradleIssue>

Not sure how your MCVE is related to your question. The error you show in the readme is because you didn't do `libs.plugins.dokka` and so on, but `libs.kotlin.dokka`.

Yes.  Correcting the plugins block to the below allows the project to be successfully executed.
```plugins {
    `java-library`

    alias(libs.plugins.m.versions)
    alias(libs.plugins.dokka)
    alias(libs.plugins.kotlin.jvm)
}```

```    @Suppress("DSL_SCOPE_VIOLATION")
    alias(libs.plugins.m.versions)```
Seems to suppress the IDE error.

Yes, or you just ignore it, or install the little work-around plugin mentioned in <https://youtrack.jetbrains.com/issue/KTIJ-19370> :slightly_smiling_face:

You’ll see that pattern where a plugin (perhaps defined in buildSrc) applies a 3rd party plugin, requiring the class files to both apply the plugin and likely configure it.  Plugin versions are needed where they are applied - if you have multiple locations applying plugins (plugins applying plugins, subprojects applying plugins, etc) may need to look at pulling all those into convention plugins and applying plugins in a uniform way, and from there looking to standardize version management.

Yes, you can use a version catalog of the parent build in `buildSrc/build.gradle(.kts)` by importing it in the `buildSrc/settings.gradle(.kts)`.

Fwiw, I've been using a helper function to generate the plugin marker coordinates from the plugin ID for a while:
```dependencies {
    implementation(plugin(id = "com.diffplug.spotless", version = "5.14.1"))
}
// <https://docs.gradle.org/current/userguide/plugins.html#sec:plugin_markers>
fun plugin(id: String, version: String) = "$id:$id.gradle.plugin:$version"```
and am now using version catalogs with a similar function:
```dependencies {
    implementation(plugin(libs.plugins.spotless))
}
// <https://github.com/gradle/gradle/issues/17963>
// <https://docs.gradle.org/current/userguide/plugins.html#sec:plugin_markers>
fun plugin(plugin: Provider&lt;PluginDependency&gt;) = plugin.map { "${it.pluginId}:${it.pluginId}.gradle.plugin:${it.version}" }```


<@UDC9Q9RD0> Looks useful, thanks!

Does it work with any plugin? For example the SpotBugs Gradle plugin is using a different pattern: <https://plugins.gradle.org/plugin/com.github.spotbugs>
```dependencies {
  classpath "com.github.spotbugs.snom:spotbugs-gradle-plugin:5.0.6"
}```
```id "com.github.spotbugs" version "5.0.6"```

Ah, the marker artifact is always using the same pattern. :bulb:

It works with every single plugin as that's how Gradle does it when you use `plugins { id("com.github.spotbugs") }` (see the link in comment next to the function). The thing is, that _plugin marker artifact_ is only a POM that depends on the _actual_ artifact of the plugin: <https://plugins.gradle.org/m2/com/github/spotbugs/com.github.spotbugs.gradle.plugin/5.0.6/com.github.spotbugs.gradle.plugin-5.0.6.pom>

<@UDC9Q9RD0> that function only works if the plugin id is following a concrete naming convention no?

No. As soon as it's usable with the plugins DSL, this is how Gradle resolves it itself (and if it's not usable with the plugins DSL, you already know exactly which Maven coordinates to use)

<https://docs.gradle.org/current/userguide/plugins.html#sec:plugin_markers>
&gt; Since the `plugins {}` DSL block only allows for declaring plugins by their globally unique plugin `id` and `version` properties, Gradle needs a way to look up the coordinates of the plugin implementation artifact. To do so, Gradle will look for a Plugin Marker Artifact with the coordinates `plugin.id:plugin.id.gradle.plugin:plugin.version`. This marker needs to have a dependency on the actual plugin implementation.


It's also independent of the coordinates of the actual code jar.
Because one code jar could contain multiple plugins.
That's why the plugin marker artifacts are separate.

No, there is no way, except if you control both plugins.

where the extension property type is a NamedDomainObjectContainer, one can use `whenObjectAdded`to register a callback.

depending on the use case, creating a derived provider can be of use: PluginA.extension.property.map { // do what is needed here, to be executed when this provider is resolved }

Then don't have a property in extension `A` but have a method that does the configuration and that can then inform interested other parties like plugin B or similar.

<@U02S31Y7J2K> I can't use a provider/property bc they don't allow notification when the property is set - it still needs to be pulled

fair enough, though for a set of use cases it may be possible to avoid the notification and create a derived provider that pulls in values at resolution time.

Yep, <@URQ797WRW> my question is just about what type to use, instead of manually managing callbacks

You probably have to do it manually. You can have internally `Property`s that you set from the method call and expose them as `Provider`s so that they can be wired to other properties easily.

I need to execute the callbacks before `afterEvaluate` but after the property is set.

The property is set once during evaluation, so I need to execute the registered callback immediately once it's set

something like
```fun propertyA(value : String) {
  propertyA.set(value)
  callbacks.forEach {
    it.execute(value)
  }
}```

FTR I went with this solution:

```abstract class ModuleConfigPluginExtension @Inject constructor(
    project: Project,
    objects: ObjectFactory
) {
    private val projectPath = project.path
    private var module: Module? = null

    private val moduleCollection: DomainObjectCollection&lt;Module&gt; = objects.domainObjectSet(Module::class.java)

    fun setModule(module: Module) {
        if (this.module != null &amp;&amp; this.module != module) {
            error("`${projectPath}`: Module has already been set with a different value. Module can only be set once")
        }

        if (this.module == null) {
            this.module = module
            moduleCollection.add(module)
        }
    }

    fun whenAdded(block: Module.() -&gt; Unit) {
        moduleCollection.configureEach {
            block(this)
        }
    }
}```
then plugins can use this extension function:

```fun Project.whenModuleConfigAdded(action: Module.() -&gt; Unit) {
    the&lt;ModuleConfigPluginExtension&gt;().whenAdded(action)
}```


I think there’s a gap in the gradle APIs because when I line up code with `afterEvaluate { }` - I actually don’t about all evaluation - just evaluation of a specific plugin/extension

that’s the premise for the Property/Provider API - allowing them to be resolved as-needed, at execution time, sidestepping the race-condition of afterEvaluate (ordering of listeners, etc).  Of course, that presumes that all APIs are using Property/Provider, and a few other gaps.

yeah. Unfortunately cannot use `Property/Provider` to react to value changes at configuration time

you often don’t actually need to do that - chaining providers together and creating derived providers satisfies a swatch of use cases.  your use case (a list/set of elements to respond to) isn’t handled by the Property/Provider API, though Gradle does still offer an option.

for example, the below allows propertyY to be chained to propertyX - whenever (at execution time) propertyY is resolved it will use the current value for propertyX.
```extensionB.propertyY.set(extensionA.propertyX)```

…or creating derived providers:
```extensionB.propertyY.set(extensionA.propertyX.map {
  
  // do some lazy-evaluated stuff here based on propertyX's value
  // invoked when propertyY resolved

})```

Any dynamic dependency? Even if it's transitive

are the POM files referenced, either directly from your project or as a transitive dependency, with a dynamic version or a SNAPSHOT?  e.g. latest.release, 1.+, 0.1.0-SNAPSHOT.  Those have a cache time-to-live and will be periodically redownloaded (cache TTL is configurable)

a Gradle build scan (`--scan`) would help identify dependency resolution here.

thats the repo:
```maven {
    url = URI("<https://packages.confluent.io/maven/>")
}```
and the deps are stable kafka libs, no snapshots

another consideration is the order of repositories - each repository will be checked for dependencies in the order declared.  is it perhaps checking for artifacts that don’t exist in that repo (but exist in the next repo)?  in that case, there are content filters to limit what a repo is used to resolve.

in any event, run a scan to understand what is being resolved from where.

ok sorry if thats a stupid question, but can i be sure that the scan does not upload sensitive info?

my guess is that the 3rd party repo is missing some metadata and maven tries to fetch the missing data from maven central

if you are worried about scan uploading sensitive info, start with running with --info and --refresh-dependencies, grepping all the download log entries to understand what is being resolved.

for completion, you can find <https://docs.gradle.com/enterprise/gradle-plugin/#captured_information|here> the list of captured information when publishing a Build Scan. When publishing to <http://scans.gradle.com|scans.gradle.com> you can always delete the Build Scan when you don’t need it anymore and no trace of it will remain in the system.

have always used toolChain for consistency between IDE / CLI / CI builds.  IntelliJ will take it from there.

What is this "toolChain" you speak of?  :slightly_smiling_face: Is that in gradle?

In gradle (<https://docs.gradle.org/current/userguide/toolchains.html|docs>).  A typical usage would be something like
```java {
    toolchain {
        languageVersion.set(JavaLanguageVersion.of(11))
    }
}```
One can also set the JVM vendor (Adoptium, etc) to use if so desired.  Note the toolchain JVM version is separate from the JVM used to execute Gradle.  For all our Gradle builds, the Gradle JVM is 17 with the toolchain set per-project as required.

Hate to keep buggin', but... if I have `--add-exports` that I need for part of my build, and I'm now using toolchains, I can't seem to use those w/ the `--release` flag.  Can I still suppress `--release` or is there something else I need to do to add some exports?

shouldn’t be a problem - it’s still the same JavaCompile task / settings, internally the logic figures out which JVM to execute.  `--release` may not be required, as the toolchain explicitly sets the JVM version to use.

normally, setting `sourceCompatibility` and `targetCompatibility` would suppress `--release` flag, but we can't use those anymore w/ toolchain.

they aren’t needed with toolchain - the compatibility stuff is only for when you are using one JVM for multiple things (running Gradle, compiling X, Y, Z, etc) - with toolchain you can separate those concerns.

Why should you use `source- / targetCompatibility` if you are using Java toolchains feature? One practially superseeds the other. You configure the toolchain that you would have set for compatibility.

we need `--add-exports`.  This does not work with `--release` and using toolchains causes `--release` to be used.

I'm saying, previously, the use of `source/targetCompatibility` was suppressing `--release` and allowing `--add-exports` to work.

Toolchains should not use `--release` I think. It is not necessary, as the correct Java version is used to execute the compiler, so `--release` would be superfluous, wouldn't it?
Besides why should add-exports not work with release?

In which case `--add-exports` wouldn't make any sense

we only add the exports when java version &gt;8.  I'll check gradle/IJ are all on 17....

are there arguments, such as --release, passed to the JavaCompile task?

ok.  can’t recall seeing `--release`  being part of the arguments, worth figuring out where that is coming from.

It’s perhaps this issue: <https://github.com/gradle/gradle/issues/18824>

there’s a reasonable workaround in there that hopefully with sidestep this.

Hm, strange, it wonder why the release flag is set at all, as the correct jdk is used already. Must have remembered wrongly it seems.