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

Gradle Community

This error: `Unrecognized option: --add-opens` would seem to indicate an older Java version (&lt; Java 9).

This path is odd: `/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java` - ensure you have a full, recent JDK installed.

likely an incompatibility between a Gradle plugin and the Gradle version in use.

Is there a way to figure out what gradle version it works with?

generally downloaded projects will include gradle/wrapper/gradler-wrapper.properties that lists the Gradle distribution (version) to use.  This wrapper information is used when executing Gradle from the project root via `./gradlew`

The way we have addressed this problem for toolchains is to switch our decompression library from Ant to Apache Commons Compress in Gradle `8.0` (soon to be released). As far as I can tell Gradle still uses Ant `1.10.11` at this time, so I would say the version of Ant in Gradle `7.6` is not high enough. If there will be a Gradle `7.6.1` and if the version of Ant could be bumped in that, is an open question.

A shared build service is the idiomatic pattern to aggregate results across a build.  Sharing state between tasks is a code smell.

Maybe this is important to know: Not only do I want to aggregate across task but also across projects. Would a shared build service still work in that case?

Nvm, this is actually documented. But just to be clear: I do not want to access other Task instances from my aggregation task. In my scenario, many tasks create many files. And the only thing the aggregation task does is combine them. I control all the file formats. In this case, would you still suggest a build service?

Just asking because I've never heard of this pattern and I am also unable to find where the docs would suggest that

How is the task disabled? seems to me that if the task is disabled its output directory should not be included with your aggregate tasks input collection and all would be well

if the inputs to your aggregate task didn't change I would say it is working as expected

Not sure what you are asking, so I'll try to further describe my issue. Maybe this clarifies stuff for you:

I am creating a Gradle Plugin. This plugin is creating multiple analysis tasks that do analysis on Configurations. Each task is writing its results in a file. I also create a task that is aggregating these results.
This aggregation task has a ConfigurableFileCollection as an Input that has all those analysis task declared as `from` . This all works fine.

But if one of the analysis tasks is disabled in the build script (e.g. via `tasks.get("analysis").enabled = false` ), then I still have the tasks output in my file collection. But this output is now old and therefore useless/misleading. Instead, I'd want the output file to disappear from my file collection.

Does this make things more clear?

yes. so you are in the "working as expected" because even though your disabled task doesn't run, it still has an output that is being included as an input to your aggregate task

to do what you are wanting you might add a custom property to your task rather than the built in `enabled` then in your task action:
`if(!customEnabled) //delete outputs else // do work`

Hmm but for example the Jar task also shouldn't run on outdated class files, if "compileJava" was disabled, right?

Ah yeah! That workaround would work for me :slightly_smiling_face:

I understand what you are saying. I just am not aware of if a disabled task should be actively removing its outputs from previous runs.

its just that a disabled task still has to be fully configured to know if it is disabled or not

Yeah, I understand :slightly_smiling_face: Thanks for your help :slightly_smiling_face:

```fun repos(): List&lt;ArtifactRepository&gt; = TODO()

val repos: Provider&lt;List&lt;ArtifactRepository&gt;&gt; = project.settings.dependencyResolutionManagement.repositoriesMode.map {
  @Suppress("NULLABILITY_MISMATCH_BASED_ON_JAVA_ANNOTATIONS")
  if (it == RepositoriesMode.PREFER_PROJECT) {
    repos()
  } else null
}
project.repositories.addAllLater(repos)```

I asked on StackOverflow here: <https://stackoverflow.com/questions/75115285/cmake-imported-library-not-included-in-gradle-output>

This doesn’t appear to be Gradle related - it’s sole task looks to be invoking flutter.bat, which is failing.  You’ll need to analyze the output of flutter.bat to determine why it is failing.  From the partial error message it looks like a pathing or permissions issue.

```Ok thank you very much for your answer, do you know how I can fix this?```


Even if my application compiles on the web?

I have a plugin `FooPlugin` creating an extension:
```interface FooExtension {
  val foos: NamedDomainObjectContainer&lt;Foo&gt;
}
abstract class Foo(private val name: String): Named {
  override fun getName() = name
}
class FooPlugin : Plugin&lt;Project&gt; {
  override fun apply(project: Project) {
    val fooExt = project.extensions.create("foo", FooExtension::class.java)
    fooExt.foos.register("testFoo")
  }
}

// build.gradle.kts
foo.foos.testFoo // Unresolved reference.```

```interface FooExtension : NamedDomainObjectContainer&lt;Foo&gt;

class FooPlugin : Plugin&lt;Project&gt; {
    override fun apply(project: Project) {
        project.extensions.create&lt;FooExtension&gt;("foo", ...)```

your original _might_ work if <https://github.com/gradle/gradle/issues/9264> is resolved (although I think you will still need a unique type for the container), but it won't currently

Thanks for the link! But now I am unable to create an instance of the extension
```Could not create an instance of type FooExtension.
      &gt; Could not generate a decorated class for type FooExtension.
         &gt; Cannot have abstract method NamedDomainObjectCollection.getAsMap().```

you might have to do it the long-winded way,
```internal class DefaultFooExtension @Inject constructor(
    private val objects: ObjectFactory,
) : AbstractNamedDomainObjectContainer(), FooExtension {
    override fun doCreate(name: String): Foo = objects.newInstance(name)
}

val fooExtension = project.objects.newInstance&lt;DefaultFooExtension&gt;()
project.extensions.add&lt;FooExtension&gt;("foo", fooExtension)```

hmm AbstractNamedDomainObjectContainer is internal. I'm not entirely sure what the correct public way to do this is

maybe you could
```project.extensions.add("foo", project.objects.domainObjectContainer&lt;Foo&gt;())```
but you wouldn't be able to add your own functions to it

Yeah, that works, nice. As a workaround, I add two extensions, one typed holder containing the elements and another for my functions. Thank you!

blows up from this call -&gt; <https://github.com/britter/maven-plugin-development/blob/main/subprojects/plugin/src/main/kotlin/de/benediktritter/maven/plugin/development/task/GenerateMavenPluginDescriptorTask.kt#LL105C17-L105C69|https://github.com/britter/maven-plugin-development/blob/main/subprojects/plugin/s[…]en/plugin/development/task/GenerateMavenPluginDescriptorTask.kt>

```Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 61```

so the plugin depends on <https://github.com/apache/maven-plugin-tools> v3.6.0 which uses very old ASM version (supports Java 11)
v3.6.1 updates the ASM version to support Java 17

You can upgrade to `3.6.1` or higher on you plugin classpath. If you use buildSrc (or included plugin build) add this to your `buildSrc/build.gradle`

```dependencies {
  implementation(platform("org.apache.maven.plugin-tools:maven-plugin-tools:3.6.4"))
}```
If that fixes the issue, I think <@UF9HQE743> will be happily accepting a PR to upgrade the dependency version in the plugin.

out of curiosity, I just gave it a spin - `buildSrc` platform constraints didn't propagated to the projects for me

instead, adding this to the buildscript of a using the plugin did work:
```buildscript {
    dependencies {
        classpath(platform("org.apache.maven.plugin-tools:maven-plugin-tools:3.6.4"))```

this caused another issue due to a dependency changing their classifiers across releases, which seemed to be fixable with
```buildscript {
    configurations.classpath.resolutionStrategy.eachDependency {
        if (requested.group == "org.sonatype.sisu" &amp;&amp; requested.name == "sisu-guice") artifactSelection {
            if (requestedSelectors.any { it.type == "jar" &amp;&amp; it.classifier == "noaop" })
                selectArtifact("jar", null, "no_aop")```

I didn't actually test if anything about the plugin worked, just that `./gradlew buildEnvironment` showed that the expected dependencies were resolved

Opened <https://github.com/britter/maven-plugin-development/pull/89>

When updating to 3.6.2+ getting failures with that `noaop` jar
```Execution failed for task ':plugin:compileKotlin'.
&gt; Error while evaluating property 'filteredArgumentsMap' of task ':plugin:compileKotlin'
   &gt; Could not resolve all files for configuration ':plugin:compileClasspath'.
      &gt; Could not find sisu-guice-3.2.3-noaop.jar (org.sonatype.sisu:sisu-guice:3.2.3).
        Searched in the following locations:
            <https://repo.maven.apache.org/maven2/org/sonatype/sisu/sisu-guice/3.2.3/sisu-guice-3.2.3-noaop.jar>```

is it possible to have typesafe project accessors for included builds?

This at least is about a 3500 modules build: <https://developer.squareup.com/blog/herding-elephants/>
But I didn't actually read it, so I don't know whether there are performance measurements included.

Potential benefits of multiple modules:
• smaller amount to compile when changes occur (depends on the scope of the changes);
• compiling, testing in parallel across modules/projects;


Also see <https://developer.squareup.com/blog/celebrating-the-release-of-android-studio-electric-eel/>
Note that Square is using Android Studio. The sync/import process is very different from IntelliJ, the Studio one is more expensive. Also, IntelliJ itself doesn't leverage parallel TAPI model building yet.

There is no included build / convention that calls the ExampleTask itself. There is also no single task that has a `dependsOn` or similar on that particular task.

But when running `gradle build` the task gets executed anyways. The gradle stacktrace itself does not provide any information, but the console output will occur.

where do you create/register the task? just defining a task class shouldn't do anything by itself.

As mentioned the task is never registered at all. The task source is part of a included build and lies in the `src/main/kotlin/org/example`  directory. Also the `src/main/kotlin` directory contains all conventions - and none of them is referencing the task at all

Maybe use `sourceSets.main.java.sourceDirectories` rather than `srcDirs`, as `sourceDirectories` maintains dependency information, so the task resolving the source dirs should have an implicit dependency on the tasks that produce those source dirs.

exactly what I was looking for. somehow I missed that one :slightly_smiling_face: thanks <@UDC9Q9RD0> that api can you some cleanup :rolling_on_the_floor_laughing:

I see this in the javadoc for `getSourceDirectories`
&gt; Generally, it is preferable to use this method instead of getSrcDirs()
I feel like the javadoc for `getSrcDirs` should have a similar warning, and it should also be deprecated maybe?

I found that there are 2 `.class` on the input that are different:
• `java.base/java/lang/invoke/DelegatingMethodHandle$Holder.class`
• `java.base/java/lang/invoke/DirectMethodHandle$Holder.class`
I found that using `org.gradle.caching.debug=true`

I'd bet "no" on this one but curious about the answer

Overall included build plugins don't really care about the version, do they?

It could be `1.0.0` or `x.y.z` and it'll be in the classpath no matter what

So it deosn't really make sense to put them in a *versions* catalog

the problem is I have to remember the exact id if not as there is no codegen if it is not buildSrc, I think it is an use case which should be supported 

I mean in all cases you need to put the id in 2 places:
• `build-logic/build.gradle.kts` (`gradlePlugins {}` block)
• `yourmodule/build.gradle.kts` or `libs.versions.toml`

Writing this I realize if you have several modules, it's n vs 2

Could you do something like
```plugins {
  // Can build-logic contribute anything here?
  `my-plugin`
}```

It's working for `kotlin-dsl` and others but maybe it's only available to a few select plugins

But I think the KGP contributes `kotlin("jvm")` so you might be able to do something ?

```fun PluginDependenciesSpec.`my-module`(): PluginDependencySpec =
    id("com.example.mymodule")```


The problem is remember the id and/or remember to use `get().pluginId`, both are annoying, first because I always forget it, second because I have to sync two times as I can't write it without autocomplete, and I will forget it too without autocomplete :upside_down_face:

And I can't create manually the accessors if I am not using buildSrc, they fail for me, and even if that work, it lacks consistence too

```plugins {
   alias(libs.plugins.android.library)
   alias(libs.plugins.kotlin.android)
   alias(libs.plugins.my.convention)

   id(libs.plugins.my.convention.get().pluginId)
   id("my-convention")
   `my-convention` // this is crashing using an extension property over the plugin spec class
)```

I think it is easier to just add it to version catalogs, but I don't understand what is the limitation to just let not setting the version in the catalog instead of Gradle trying to check if the plugin is or not in the classpath and so on, probably it exists but I would expect that under the hood it just uses `id` + `version`  or just `id` based on what is defined in the `alias` + the catalog

But then we need to rename "versions catalog" to "dependencies catalog" :troll:

I think I saw a discussion about that somewhere

And "versions" was a conscious choice, not sure why

I have remembered this issue: <https://github.com/gradle/gradle/issues/17968>

and... I was there, I forgot it, that fits with _I always forget it_ which is a general thing if I don't repeat something 1000 times :upside_down_face:

but I think you can have libraries without versions

the limitation is only happening with plugins

I will go for this option from Vampire

&gt; • or use the settings DSL to declare the plugin without version


if you use them for work, you should ensure you have approvals from within your company. I'm not aware of any restrictions on the use of public build scans, though. The pricing page you reference is for Gradle Enterprise, which is a more powerful version of public build scans

Your initial thinking is correct - simply using gradle-build-action enables caching with no additional configuration required.  That will cache the Gradle distribution, downloaded dependencies, and a few other tidbits.

Does the action really enable the build output cache by default?
I wouldn't have expected that.

The github build action is unrelated to org.gradle.caching.

So yes, he has to enable the build output cache for his project either by commandline option, or by configuring it in `gradle.properties`, even when using that action, right?

that is correct, if build output caching is desired.  Even without that the Gradle build action will cache the Gradle distribution, dependencies, generated JARs, etc.

If you go with <https://github.com/burrunan/gradle-cache-action>, they you’ll get Gradle Build Cache service backed by GitHub cache, and incremental dependency cache (=PR builds could reuse cache from main branch + delta)

But still only if enabled for that specific build, not enabled by default, or?

I think it adds `buildCache` configuration by default

It adds a build cache configuration for remote build cache that is backed granularly by the GHA cache facility, yes.
But still this will only be used if Gradle build cache is actually enabled for a build.

&gt;By default, the action enables the `local` build cache, and it adds a remote build cache that stores the data in GitHub Actions cache

So if you merely apply the action, then it would enable build cache.

The README indicates one needs to enable the build cache:
&gt; This is how you can enable local build cache (don’t forget to add `--build-cache` option or `org.gradle.caching=true` property):
&gt; ```// settings.gradle.kts
&gt; val isCiServer = System.getenv().containsKey("CI")
&gt; // Cache build artifacts, so expensive operations do not need to be re-computed
&gt; buildCache {
&gt;    local {
&gt;        isEnabled = !isCiServer
&gt;    }
&gt; }```


Seems to contradict the previous paragraph in the README:
&gt; By default, the action enables the `local` build cache
Also, wondering why it shows an example of enabling the build cache for CI (the only place where the GitHub action runs) that has the build cache disabled for CI:
&gt; ```// settings.gradle.kts
&gt; val isCiServer = System.getenv().containsKey("CI")
&gt; // Cache build artifacts, so expensive operations do not need to be re-computed
&gt; buildCache {
&gt;    local {
&gt;        isEnabled = !isCiServer
&gt;    }
&gt; }```
&gt; 

&gt; The README indicates one needs to enable the build cache
It is in case you want to enable caching when building the project locally

Confusing.  How is that relevant to a GitHub action?

it is not completely relevant, however, it is a way to promote Gradle Build Cache feature.
I guess it is under-used one

Would suggest rewording to make it clear what applies to a non-CI build.

With `gradle-build-action` the cache is only written to from your repo's default branch by default

Ah, right, then I remembered wrongly about the default cache.
The readme does not really contradict.
It shows how to disable the local build cache on CI but enable it on local builds and remindes that you need to enable the cache using argument or Gradle property *when running local builds*.
On CI with ephemeral agents the local cache only makes sense if you run multiple Gradle builds within the same action that could reuse things from the cache, otherwise it is just a waste of time.

<@URQ797WRW> doesn't the GitHub action copy the local cache from previous runs (on a default branch) into each ephemeral runner?

Does it?
Well then, dunno why you should disable it on CI

Well, obviously it does, as there is a setting to switch it off.
You could switch it off to save cache space and then disable the local cache. :slightly_smiling_face:

&gt; You could switch it off to save cache space and then disable the local cache
The behavior should be sane: it should not do dumb things by default, so disabling things at random is not the best option.
If it does dumb things by default, then it is better to file a bug.

The switches are there to fine-tune in case of weird requirements/issues.

Mind telling us then, why the documentation example suggests to disable the local build cache on CI? :slightly_smiling_face:

I can’t tell right now, so I filed <https://github.com/burrunan/gradle-cache-action/issues/57>

Btw. while we are at it, did you also consider pros and cons regarding the official `gradle-build-action`?
In the readme there is only a comparison to `gradle-command-action`.
For example as far as I know your action does not support caching the configuration cache yet while the official does. :slightly_smiling_face:

To be fair, the key difference is that `burrunan/gradle-cache-action` is not endorsed by Gradle, so I am afraid it will not get traction.
Just like JCenter died, because “Maven Central” was always “the official” repository, so JCenter had doomed to be the second level citizen.

I believe `gradle/gradle-build-action` misses:
• remote build cache, including multi-cache when you fetch from GitHub Actions cache, and the remote build cache configured in the project
• Incremental file-based cache storage. `burrunan/gradle-cache-action` implements incremental storage for file-based caches (e.g. in case `build cache` is disabled)
• Maven repository caching. For instance, if your build uses Maven-based builds as prerequisite, then you might want to cache `.m2/` as well. Of course, it is incremental, and subsequent PR-based builds can reuse “main cache + previous PR cache”
• Build error propagation from the log to file diff UI: <https://github.com/pgjdbc/pgjdbc/pull/2720/files#file-pgjdbc-src-main-java-org-postgresql-package-info-java-L6>
• Build scan is not surfaced. For instance, with `burrunan/gradle-cache-action`, the links are easier to use: <https://github.com/pgjdbc/pgjdbc/actions/runs/3929085356>
• Kotlin. `gradle/gradle-build-action` is TypeScript-based while `burrunan/gradle-cache-action` is Kotlin-based
There might be other minor differences

Would probably make sense to add that to the readme too. :slightly_smiling_face:
I'm for sure not the only one wondering and without guidance on the differences, I'd probably also prefer the official action if I were not already using your action from the time when the official action did not exist yet.

No need to cry, I think I just expressed unluckily.
I mean if I would not know that your action has better features (besides the missing configuration cache caching support) I would probably have chosen the official one if I were to choose and not have the information you posted. That's why I suggested you add the information to the readme so that people read it might see that your action is better and choose it. :-)

Reading from <https://github.com/gradle/gradle/issues/17306>, looks like there's `-x` but I need this programmatically

`enabled = false` still executes dependencies

I guess there's no way to modify the task graph while building it or something like this

Oh, does it? I meant to remember `-x` basically sets enabled to false. Seems I'm wrong then. :-(

You can use
```gradle.startParameter.setExcludedTaskNames(listOf(...))```
That is the property `-x` is setting and it works to set it from a build script too, I just tried.

<https://docs.gradle.com/build-cache-node/#using_https>

<@URQ797WRW> Do you know how to view the admin page or the login page for gradle cache? both `/cache` , `/admin` `/cache-admin`  and `login`gives below.

No path: <https://docs.gradle.com/build-cache-node/#accessing_the_configuration_user_interface>

I'm starting to get nervous that it's <https://docs.gradle.org/8.0-rc-2/userguide/upgrading_version_7.html#strict-kotlin-dsl-precompiled-scripts-accessors|https://docs.gradle.org/8.0-rc-2/userguide/upgrading_version_7.html#strict-kotlin-dsl-precompiled-scripts-accessors>

If it is, is there any way to achieve the previous behavior?

If you have a reproducer please open an issue, so team can inspect if it’s an expected behaviour or a bug. Since it’s 8.0-RC2 issue it will get attention soon.

Feels weird to me to let the consumer choose the detekt version but still apply the plugin. Is that a common thing?

I would have expected either:
1. a property in your plugin extension (`myPlugin { detektVersion.set(foo) }` ) (or better see below)
2. "reacting" on a plugin that is already applied (`withPlugin {}` )

Option 1 would be hard though. Because when the "myPlugin" is applied it adds the extension and it is not configured to know the detekt version.
Should probably more be a `myPlugin { useDetekt("1.2.3") }`

Accessors for the detekt plugin are then not available for the consumer though.
But yeah, would also have assumed a `pluginManager.withPlugin` instead in that case.

How does the consumer "select" the detekt version?
Is it "more convenient" than to apply the plugin in the consumer so that your plugin can react to it being applied and then just configure it?

Sorry I wasn't so clear. Here's the problem (I didn't push the branch migrating to 8.0 yet; I'll do that soon so it can be reproed) <https://github.com/eygraber/gradle-conventions/blob/master/conventions-plugin/build.gradle.kts#L25|https://github.com/eygraber/gradle-conventions/blob/master/conventions-plugin/build.gradle.kts#L25>

I need that dependency on the detekt plugin so that I can use detekt related classes in the convention plugin. 

If I use `implementation` it leaks to the user's classpath and if they depend on detekt plugin as well it could override the version they use.

The same issue applies to all the other `compileOnly` dependencies in that file. I'm just using detekt as an example

No, I think you were perfectly clear, you just didn't understand what we say. :smile:
If someone applies your detekt convention plugin without adding detekt in the intended version to the classpath, your convention plugin does not know which version to apply.

So my question again.
How do you expect the consumer of your plugin to specify the detekt version to be used?

If you e.g. expect him to add the detekt plugin in the intended version to the classpath,
he could as easily apply the detekt plugin.
Then your convention plugin can have `compileOnly` and instead of applying the detekt plugin it can simply react to the fact your consumer applied the detekt plugin using `pluginManager.withPlugin("io.gitlab.arturbosch.detekt") { ... }`.
He could even apply your convention plugin (or all your convention plugins) without applying the detekt plugin and your convention plugin would then simply do nothing, as the `withPlugin` closure will never be invoked.

I prefer if the convention plugin applies the plugin because otherwise the user would have to apply two plugins; detekt and my convention plugin. Some of my projects have hundreds of subprojects so that's a pain. 

To add detekt to the classpath it's a single line in the root build file.

I'll file an issue with my use case, but I do understand why that behavior wouldn't be supported.

&gt; Some of my projects have hundreds of subprojects so that's a pain.
I see
&gt; After updating to Gradle 8.0-rc-2 the plugins that I apply in the precompiled script plugins are no longer found
Might also be a classloader thingie. Are you using `buildscript {}` by any chance, in which case you could try this?
```// rootProject/build.gradle.kts
plugins {
 id("io.gitlab.arturbosch.detekt").version(foo).apply(false)
}```

Just to make sure we're on the same page, the failures are happening when I build my conventions plugin project, not in the projects that consume the convention plugin.

oohoh well.. then I don't know. I would not have expected this to be checked when doing `./gradlew -p build-logic build` or so...

I'm pretty sure it's because of <https://docs.gradle.org/8.0-rc-2/userguide/upgrading_version_7.html#strict-kotlin-dsl-precompiled-scripts-accessors|https://docs.gradle.org/8.0-rc-2/userguide/upgrading_version_7.html#strict-kotlin-dsl-precompiled-scripts-accessors>

Pre 8.0 there were warnings, but the plugin built correctly.

I guess you tried
```systemProp.org.gradle.kotlin.dsl.precompiled.accessors.strict=false```
?

I'm about to, but I don't think it'll work (they say they're getting rid of it)

Probably not the answer you're looking for but you could write your plugin as "plain" Kotlin (without `kotlin-dsl` ). You won't have generated accessors but you'll be able to apply the detekt plugin dynamically I believe

Ah, I see.
So does it fail during the `generatePrecompiledScriptPluginAccessors` task?
Could well be that this is a bug that the `compileOnly` dependencies are not added to the dummy projects classpath that is used to generate the accesors.

You could either do like <@UMCNY0BFH> suggested, or you could not use the `plugins { ... }` block in your convention plugin but use the legacy `apply(...)`. Then you also do not get accessors and need to use the more verbose syntax but can keep them as precompiled script plugins.

```systemProp.org.gradle.kotlin.dsl.precompiled.accessors.strict=false```
actually worked! I guess it's just deprecated now, but still works?

It is happening during `generatePrecompiledScriptPluginAccessors`

But yeah, you should open an issue about that.
Makes sense to just add it to the classpath using the root build script and just apply the convention plugin in subprojects.

Yeah, I expect that setting to be removed at some point, but probably only in Gradle 9+.
But that's just a wild guess.

<@U02DF9JDXJM> filed <https://github.com/gradle/gradle/issues/23576>

We sign plugins just by applying the "signing" plugin and then configuring the details in `gradle.properties` via

```signing.keyId=...
signing.password=...
signing.secretKeyRingFile=...```
I did not see any such issues when moving from `7.6`  to `8.0-rc-1`

Sorry, I'll delete, this was a misconfiguration on my part

Was able to accomplish this using the following code in the script plugin
```interface ExtJSPluginExtension {
    Property&lt;String&gt; getAppDir()
}

def extension = project.extensions.create("extjs", ExtJSPluginExtension)```

Yes and you should! :slightly_smiling_face:  This is the DSL *Extension* concept of Gradle.
There are many things you can do there, but the most compact way is to create an Interface (using Java/Kotlin/Groovy) with `Property&lt;..&gt;` s and register it as an extension.

I have a quite minimal example here:

<https://github.com/jjohannes/understanding-gradle/blob/main/07_Implementing_Tasks_and_Extensions/my-build-logic/java-plugins/src/main/kotlin/my-java-application.gradle.kts#L8|https://github.com/jjohannes/understanding-gradle/blob/main/07_Implementing_Tasks_[…]gic/java-plugins/src/main/kotlin/my-java-application.gradle.kts>

<https://github.com/jjohannes/understanding-gradle/blob/main/07_Implementing_Tasks_and_Extensions/my-build-logic/java-plugins/src/main/kotlin/myproject/tasks/MyAppExtension.kt|https://github.com/jjohannes/understanding-gradle/blob/main/07_Implementing_Tasks_[…]/java-plugins/src/main/kotlin/myproject/tasks/MyAppExtension.kt>

<https://github.com/jjohannes/understanding-gradle/blob/main/07_Implementing_Tasks_and_Extensions/my-project/app/build.gradle.kts#L5-L7>

Thanks :slightly_smiling_face: I'll check those examples

Hi. Am I correct in stating that you can only use extension values inside blocks of lazy configuration? Otherwise the extension hasn't received its value yet, and you get this error:
```Cannot query the value of extension 'fooExtension' property 'foo' because it has no value available.```

for example like so:
```interface FooExtension {
    val foo: Property&lt;String&gt;
}

val fooExtension = extensions.create&lt;FooExtension&gt;("fooExtension")

tasks {
    // doesn't work
    println(fooExtension.foo.get())

    // works
    withType&lt;Test&gt;().configureEach {
        println(fooExtension.foo.get())
    }
}```

<@U04JU92EYK1> I just ran into this myself. I had to use project.afterEvaluate to get the extension values to configure my "jar" task, but it seems dirty.

edit: Found out that because I am configuring the jar task with a closure, it creates and configures the task eagerly. By removing the closure and using tasks.named("jar") { I am able to pick up the extension values.

Ideally, you won't have to call `get()` at all. Instead, you  just pass the provider in the task configuration. Then `get()`  is only called during task execution. That's the idea behind the provider/property concept - you only pass around references to values. This way, the order in which things are done during configuration no longer matters.

Some Tasks in Gradle and plugins unfortunately do not support providers yet. :confused: Then what you describe is usually sufficient - use task configuration avoidance (`named()` / `forEach()`) so that `get()` is called late in the configuration phase.

Still, I would be interested why you had to call `get()` for the Jar task. The API of the task is not perfect, but usually there is some way to use it without calling `get()` already. Mind to share an example?

Hi guys, I encountered a wired issue when running tests in Github actions, post it  on Stackoverflow, <https://stackoverflow.com/questions/75169922/outofmemoryerror-in-gradle-springboot-kotlin-coroutines-project>
How to find the root cause of this error. Thanks.

My groovy is a bit rusty but I believe you're looking for `mainClassName`

Mmm scratch that, doc says `mainClass = 'foo'` <https://docs.gradle.org/current/userguide/application_plugin.html>

Does this work?
```setMainClassName('<http://com.company.project.pqr.app.app|com.company.project.pqr.app.app>')```


Worth checking Gradle 5.0.0 docs:
<https://docs.gradle.org/5.0/userguide/application_plugin.html>

replacing mainClass with mainClassName worked, I think my teammate is using a different version of gradle.

They are using IntelliJ so probably they don't know what version of gradle they are running

I strongly recommend using Kotlin DSL.
That immediately makes your build scripts type-safe and enables amazingly better IDE support.

Regarding Gradle version when using the IDE, I suspect your project does not use the Gradle wrapper. Imho any build that does not have the 4 Gradle wrapper files has a bug. Because they define exactly which Gradle version to use, so the IDE also uses the correct version. If you do not have the wrapper files (or do not use the wrapper to execute the build) the build might behave differently with different Gradle versions or even be invalid syntax like you had here.

_consumable_ configurations define _variants_. If you have more than one configuration with the same set of attributes, how could Gradle determine which variant to use?

No idea but it was somewhat working so far

Maybe my configurations do not need to be consumable. That might be the good fix

```configuration ':debugFrameworkIosFat' and [configuration ':debugFrameworkIosArm64'] contain identical attribute sets```

<https://youtrack.jetbrains.com/issue/KT-56019/Gradle-8-configuration-debugFrameworkIosFat-and-configuration-debugFrameworkIosArm64-contain-identical-attribute-sets|https://youtrack.jetbrains.com/issue/KT-56019/Gradle-8-configuration-debugFrameworkIosFa[…]n-debugFrameworkIosArm64-contain-identical-attribute-sets>

That has most probably nothing to do with Gradle.
Your Gradle build calls `node` and that finishes with error.
Scroll up and find and fix the actual problem.

As you are using Android Studio you might easily miss it due to this annoyance: <https://youtrack.jetbrains.com/issue/IDEA-226613/Gradle-build-on-failed-build-IDE-auto-focuses-and-shows-incomplete-error-message-which-makes-it-hard-to-understand-why-build|https://youtrack.jetbrains.com/issue/IDEA-226613/Gradle-build-on-failed-build-IDE-auto-focuses-and-shows-incomplete-error-message-which-makes-it-hard-to-understand-why-build 2> so you need to select a higher node in the tree to see the actual error details.

yes, stuff coming from parent classpaths doesn't show up in `buildEnvironment`
<https://github.com/gradle/gradle/issues/8301|https://github.com/gradle/gradle/issues/8301>

ok thanks. I did confirm we have as setting plugin that brings in the old dependency

actually, the plugin doesnt depend on http client..... i have no idea how the old httpclient is getting on the classpath

Hey, <@U04KMGKPCS1>! Welcome to Gradle! :slightly_smiling_face:

What does the directory structure look like to your `.java` file look like?

It should look like `src/main/java/com/example/Foo.java` where the package name for `Foo` is `com.example`.

`src/edu/millersville/csci406/spring2023/common/DataSourceException.java` is the path to the file.  The first line of it is `package edu.millersville.csci406.spring2023.common;`

Ah, the top level directories should be `src/main/java`. Try that.

with then the full package hierarchy inside main/java ?

Correct. Like this:

`src/main/java/edu/millersville/csci406/spring2023/common/DataSourceException.java`

Great! And once again, welcome to Gradle!

I just have to figure out `Could not find org.postgresql:postgresql:.`

Yes, it looks like you are missing the version number.

is there a way to say "whatever the most recent version number is"?

You can, but I recommend that you define the version explicitly. That way if a new version of the library is released, it will not break your code.

For that you should specify:

```org.postgresql:postgresql:42.5.1```


If you really want to use a dynamic version, you can read more about it <https://docs.gradle.org/current/userguide/dynamic_versions.html#sub:declaring_dependency_with_dynamic_version|here> in the Gradle documentation.

gets broken down here ish
<https://docs.gradle.org/current/userguide/build_environment.html#sec:project_properties>

For more context, we currently solve the problem above by restarting the machine

What is the reason to redownload, especially regularly?
Is some dependency changing white the version stays the same?
If so, you can define it as changing version, and you can configure the time how often Gradle looks for changes of changing versions.

&gt; Is some dependency changing white the version stays the same?
Correct.

&gt; If so, you can define it as changing version, and you can configure the time how often Gradle looks for changes of changing versions.
I’m aware of this feature, but we want to do it on-demand too.

Also, some question here. When will Gradle download the dependency? Is it when the checksum is different

Probably, but I don't know the exact details.

And I'm not aware of a way to just refresh one dependency besides deleting it from the cache. With snapshot versions each individual one has also a timestamp based explicit version you could use, but that's probably not what you want.

True, thanks for the suggestion.

Anyway do you know about the cache/lock issue?
&gt; but this is sometime unreliable as Gradle will download previous artifact not the new one.

I guess what is the "latest" is stored somewhere that you don't throw away, but I don't know exactly

That make sense since if we’re only removing the `files-*` , it will download the version matching with the metadata, that’s why my assumption is also a cache or lock file.

Tagging <@UFDR8S97S> in here in case he knows something :eyes:

I think the problem to solve is why this dependency is changing while the version stays the same.

Correct, but it’s currently kinda hard for us and bandwidth is limited.
For the context it’s a dynamic version generated from checksum, but the checksum do not include the dependency tree because we need to have version before project evaluation. As for why, it’s related to <https://github.com/runningcode/AndroidLocalMavenRepoAARDemo|this forked repository>.

Thanks for letting me know. I deleted the fork since I cannot recommend this approach.

I kinda assume you won't, I got it from the original since it's in my org. I'm always open for a new approach and we're a GE customer too, but this currently works for us.

What is the problem you are trying to solve?

Before going further, just to confirm, there's no lock file or other cache?
If that's the case, can we file this as a bug?

I'm not sure I understand the issue. An `aar` file does not contain version information. Therefore I cannot recommend this approach.

It's related but not 1:1 implementation. We're using maven artifact which has POM file

I see. To be honest, I'm not exactly sure what the issue is. There are many different caches in Gradle. Without knowing what the issue you are currently experiencing is, I cannot point you to the right place.

The error is on my part. I will get back to this thread later with more detailed  issue on my part hopefully with finding in our build scans data also.

Hi <@UFDR8S97S>, I’m back, just analyzed the build scans when we debugged the issue but there’s no irregularity to it. But I got some data that might help

So here’s the issue:

• Our content and version dependencies are out of sync due to versions are currently generated from module checksum, so ABI related changes will cause an issue. (e.g kotlin data class)
• To refresh/re-download the dependency, we remove the artifact from Gradle’s cache (both files and metadata) and rebuild the app with assemble task
• *The issue arose* where removing the cache did not download the updated file from our repository and the old file persisted. This was determined by checking the sha1 hash in the cache directory. (e.g `modules-2/files-2.1/com.example/module/version/123asd123123123` ) also verified by having the same runtime crash from the ABI mismatch.
• By looking at the build scan in `Network Activity` tab, the dependency was actually download (image attached), and the Daemon also shows 0 for both previous builds and others daemon number.
• *This issue as later resolved* by restarting the machine
Please note that issue is intermittent, but once the issue arose, restarting a machine always fix it.

I almost asked the same, then have seen
&gt; the Daemon also shows 0 for both previous builds and others daemon number
so I guessed there is nothing to kill :slightly_smiling_face:

Yes, manually killing a running daemon with `./gradlew --stop` also doesn’t work.