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

Gradle Community

Hi Michal,
The snippet above doesn't show where a reference to a `Configuration` object is kept from the task.
Doc can be found here <https://docs.gradle.org/nightly/userguide/configuration_cache.html#config_cache:requirements:disallowed_types>
A `Configuration` can be used for many things, you need to figure out how it is used and replace this with supported inputs.
Could you share the place where the `Configuration` is wired to the task? Or share the configuration cache html report, stacktraces in there should be enough to figure this out.

FTR there's a <#C013WEPGQF9|> channel for the next time you have a question about it :wink:  Let's continue in this thread

configuration-cache-report.html

Hi, thank you. Next time I'll use the channel

The `MRGenerator` reference from the task drags a lot of unsupported state.

`SourceSet` instances aren't supported either by the configuration cache as stated in the doc

In this case I think you'd need a clearer separation between the state required to configure the tasks, and the task inputs. So that the former isn't referenced from the tasks.

Typically, `GenerateMultiplatformResourcesTask.inputFiles` should be a `ConfigurableFileCollection` instead. And the plugin should set it to ~ `generator.generators.flatMap { it.inputFiles }`. That way the task doesn't need to hold references to all the configuration state.

Thank you very much
I think it makes sense, I'll try to incorporate it.

You mean `ExtensiblePolymorphicDomainObjectContainer` ? I don't think we can use plain `PolymorphicDomainObjectContainer` without using internal classes.

Then maybe that.
What I need is a container where I can register different domain object types.
Practically like `tasks` or `repositories`, so like
```foo {
    create&lt;A&gt;("a") {
        // configure a
    }
    create&lt;B&gt;("b") {
        // configure b
    }
}```

Or in the end probably
```foo {
    a("a") {
        // configure a
    }
    b("b") {
        // configure b
    }
}```

In the meantime I think I got something working, at least it compiles. Just not sure whether it is the proper way to go.
I initially hoped it would be as simple as
```interface ConfigureNexusExtension {
    val foo: PolymorphicDomainObjectContainer&lt;BaseOfAAndB&gt;
}```
but it seems not to be.

<https://docs.gradle.org/current/javadoc/org/gradle/api/model/ObjectFactory.html#polymorphicDomainObjectContainer-java.lang.Class-> ?

Not sure it's possible to have the `a("a") { … }` syntax though (not without Kotlin/Groovy extensions)

That's a method, not an example.
As far as my experiments have shown there is more to it.
The domain object must explicitly be `Named`, you need to register the types manually, ...
Or I do it completely wrong

Don't care about that convenience syntax, I'll probably just make an extension function, it is an internal thing anyway, nothing that needs to be broadly compatible.

Looking quickly in Gradle's own code, it looks like testing suites use them: <https://github.com/gradle/gradle/blob/cfe5908c9b7aeeaec4912b14471aa4e7448c282d/subprojects/testing-base/src/main/java/org/gradle/testing/base/internal/DefaultTestingExtension.java#L31|https://github.com/gradle/gradle/blob/cfe5908c9b7aeeaec4912b14471aa4e7448c282d/sub[…]a/org/gradle/testing/base/internal/DefaultTestingExtension.java>, <https://github.com/gradle/gradle/blob/b0733d8c0b7bc764761d91334a80fa69f948a081/subprojects/plugins/src/main/java/org/gradle/api/plugins/jvm/internal/DefaultJvmTestSuite.java#L135|https://github.com/gradle/gradle/blob/b0733d8c0b7bc764761d91334a80fa69f948a081/sub[…]va/org/gradle/api/plugins/jvm/internal/DefaultJvmTestSuite.java>

as well as project reporting: <https://github.com/gradle/gradle/blob/8f40ea8668ce95af32532184ea8b108487d6741d/subprojects/reporting/src/main/java/org/gradle/api/reporting/ReportingExtension.java#L61|https://github.com/gradle/gradle/blob/8f40ea8668ce95af32532184ea8b108487d6741d/sub[…]/src/main/java/org/gradle/api/reporting/ReportingExtension.java>

there's little integ test coverage on plain usage for this. this seems the little most reasonable integ test I've found: <https://github.com/gradle/gradle/blob/327f679c0536453af0e953511e6e7f6397a4f76d/subprojects/core/src/integTest/groovy/org/gradle/api/internal/model/ObjectFactoryIntegrationTest.groovy#L755-L775|https://github.com/gradle/gradle/blob/327f679c0536453af0e953511e6e7f6397a4f76d/sub[…]g/gradle/api/internal/model/ObjectFactoryIntegrationTest.groovy>

but indeed the ReportingExtension usage seems a good example and uses public api around polymorphic containers

`ReportingExtension` usage is even newly added, just with 7.4 with the report aggregation changes.
But I still don't fully grasp it.
If I just do
```val foo = objects.polymorphicDomainObjectContainer(BaseOfAAndB::class)```
like is shown in those examples, I get
```org.gradle.api.InvalidUserDataException: Cannot create a MavenRepository because this type is not known to this container. Known types are: (None)
[...]
Caused by: org.gradle.api.internal.NoFactoryRegisteredForTypeException
[...]```
Instead I have to do
```val foo = objects.polymorphicDomainObjectContainer(BaseOfAAndB::class).apply {
    registerBinding(A::class, A::class)
    registerBinding(B::class, B::class)
}```
to make it work. :confused:

And that seems veeery unhandy for the convenience Gradle is usually providing

<https://github.com/sebersole/quarkus-gradle-plugin-poc/blob/74d74f90c630367075c10d31d5ba37d687b8cece/quarkus-gradle-poc-plugin/src/test/projects/simple/build.gradle#L47|https://github.com/sebersole/quarkus-gradle-plugin-poc/blob/74d74f90c630367075c10d[…]quarkus-gradle-poc-plugin/src/test/projects/simple/build.gradle>

I was never able to get the generic `name(type)` syntax to work though

As part of an answer to an unrelated question on the forums, someone had mentioned the ability to register a Class reference as an extension which helps reference it by short name.  Maybe if I had comined that here my attempts would have worked.  Something like:

```project.getExtensions().add( "SpecialType", SpecialType.class );
// or
project.getExtensions().add( "SpecialType", SpecialType.class.getName() );```
I wonder if that is what my attempts here missed.

Anyway, aside from that particular form not working that project successfully uses such a container

Besides that the `name(type)` form should probably simply work from Groovy DSL if you import the type class, or do the extensions trick so that it looks like it were auto-imported (should be the first form for the extensions trick, as you need the class instance as argument, not the name), where in the linked code is the container used? I'm probably just blind.

used as in within the plugin?  or as in used in a build file?

you probably mean in the build file... i exposed builder methods

actually looking at it more (sorry its been years since i played with that code) it really more exposes an api around the container

i do expose the container itself in the dsl so i could play with it

the referencing of the class was problematic is all i remember, not the details of why

it did not help that the things i want to contain are naturally called extensions.  so that naming quickly kept getting in the way also

i just used wrapping (composition) instead of inheritence for the container object

Yeah, had a deeper look.
Thanks, but I don't think your example is good for a simple case.
You do many custom stuff and `methodMissing` and so on and compose the container and so on.

And additionally you use custom factories which I don't need, all the domain objects for me can directly be created that's why `registerBinding` is enough for me.
But in the examples the other showed in the Gradle sources even that is not necessary but just works and I wonder why. :confused:

AFAICT, uses in Gradle all use `registerBinding` or `registerFactory`.

Yes, `methodMissing` is very much Groovy.  IIRC you use exclusively Kotlin

I know `methodMissing` and it is maybe appropriate there. If you would be in the container directly, it shouldn't be necessary as Gradle should provide the necessary magic for `newName(Type) { ... }` iirc.
But yes, I use Kotlin DSL wherever possible.
But if I would develop something for publishing, I'd make it convenient for both DSLs too of course.

&gt; AFAICT, uses in Gradle all use `registerBinding` or `registerFactory`.
Ah, yeah, didn't look right.
Probably too tired yesterday.
And because it's too scattered in the Gradle sources. :smile:
The extensions just create the container and then some more specific plugins like `JacocoReportAggregationPlugin` or `JvmTestSuites` register the bindings.

Also in Gradle everything is an interface and has an implementation, so it is absolutely necessary there anyway.
In my case I don't have implementations, I let Gradle directly implement the interface so there it seems to be a bit too verbose to being forced to do
```val foo = objects.polymorphicDomainObjectContainer(Base::class).apply {
    registerBinding(A::class, A::class)
    registerBinding(B::class, B::class)
}```
but that indeed seems to be the way to go.

Thanks guys, but there should definitely be some documentation added about polymorphic containers.
The only things I found were a two sentence mention in the manual and the DSL docs.

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

Well, don't set `-Xmx` then and it will automatically be dependent on system RAM.

Otherwise you can use for exampl environment variable to set the value per machine.

As time passes, JCenter becomes more and more unreliable, so use put `mavenCentral` before the `gradlePluginPortal`.
<https://github.com/gradle/gradle/issues/15406>

It’s generally expected to provide meaningful context - version, plugins, and - if you’re asking for help on an error - the full stack trace.  See pinned info in <#CA7UM03V3|> for deets on what to provide to maximize your changes of getting assistance.

Which includes using channels like <#C03EM93810S|>

the reason I ask is the following issue <https://github.com/gradle/gradle/issues/19474|Provide access to Gradle.StartParameter property value in a configuration cache compliant way>

Identifying every `Task` that is affected by this kind of property would not be feasible

I don't think so, but you can probably create a `ValueSource` instead to access the start parameters configuration cache safe. (If "not configuration cache compliant" meant that the value of the cache is used, no matter what the value would be now.)

Hm, no, you shouldn't even need that.
If the Gradle properties given on the commandline changes, the configuration cache is always invalidated anyway.

In which way is the example from your issue not configuration cache safe?

You should probably also add that information to the ticket

my bad. Correct me if I’m wrong - but you’re saying that this code is working as intended. Modifying the start parameter invalidates the config cache causing a re-configuration, which results in correct builds.

My issue is actually that I would want configuration to be skipped in this scenario and Gradle to just understand that the value of `Provider&lt;T&gt;` has changed at task execution time, and re-run any affected tasks if needed

&gt; my bad. Correct me if I’m wrong - but you’re saying that this code is working as intended. Modifying the start parameter invalidates the config cache causing a re-configuration, which results in correct builds.
Correct
&gt; My issue is actually that I would want configuration to be skipped in this scenario and Gradle to just understand that the value of `Provider&lt;T&gt;` has changed at task execution time, and re-run any affected tasks if needed
Still not sure what you mean.
Any change in `-P` commandline arguments will invalidate the configuration cache entry.
And if the value of that provider is a task input the task will rerun.

actually I’m seeing the config cache being re-used on a change the the CLI argument now

Not sure what you mean:
```$ gw --configuration-cache help
Configuration cache is an incubating feature.
Calculating task graph as no configuration cache is available for tasks: help
Welcome to Gradle 7.4.2.
Configuration cache entry stored.

$ gw --configuration-cache help
Configuration cache is an incubating feature.
Reusing configuration cache.
Welcome to Gradle 7.4.2.
Configuration cache entry reused.

$ gw --configuration-cache help -P foo=bar
Configuration cache is an incubating feature.
Calculating task graph as configuration cache cannot be reused because the set of Gradle properties has changed.
Welcome to Gradle 7.4.2.
Configuration cache entry stored.```

if you check out <https://gist.github.com/ZakTaccardi/a4e1b62b31a7e1069c309a2a169b1058#file-localpropertysupporttest-kt-L30>

that was failing on an older version of gradle (don’t remember which one), but works with `7.4.2`

Too long to read it now.
But as you can see from my trivial example, the configuration cache is invalidated whenever Gradle properties change,
which you said it does not for you.

this is an IDE error?
``` 'val Project.libs: LibrariesForLibs' can't be called in this context by implicit receiver. Use the explicit one if necessary```

as a side note: I find it baffling every time I go into the gradle documentation that stuff like this is not documented.
The official page talking about version catalog and TOML say nothing about this:
<https://docs.gradle.org/current/userguide/platforms.html>

```Android Studio Electric Eel | 2022.1.1 Canary 2
Build #AI-213.7172.25.2211.8571212, built on May 11, 2022
Runtime version: 11.0.13+0-b1751.21-8125866 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Linux 5.15.0-27-generic
GC: G1 Young Generation, G1 Old Generation
Memory: 2048M
Cores: 8
Registry:
    external.system.auto.import.disabled=true
    ide.text.editor.with.preview.show.floating.toolbar=false

Non-Bundled Plugins:
    idea.plugin.protoeditor (213.6461.28)
    Dart (213.7371)
    com.thoughtworks.gauge (213.5744.125)
    io.flutter (67.1.3)

Current Desktop: ubuntu:GNOME```


<@U01DUV4Q882> (not sure if I should ping you for answer)

that it is a known issue, just run `./gradlew assembleDebug` for example and check if everything is working

Do you have a link to the bug tracker? I can't consider this OK tho', is there any workaround?

you can just suppress the error with @Suppress annotation

Is there a bug I can track / add a comment for the suppress annotation?

what should I write as name of the @Suppress annotation?

<https://youtrack.jetbrains.com/issue/KTIJ-19370> this is 100% an IDE issue, not a Gradle issue. I just ignore the IDE diagnostics, no need to suppress them since everything works regardless.

<@U019L3NM4PK> this bug looks similar but it's not. It works fine for me in the `dependencies` section, the issue is in the `plugins` one.
and I'm not OK ignoring IDE error, I'd like to either Suppress it or wait for the bugfix

<https://youtrack.jetbrains.com/issue/KTIJ-19369> is the plugin-specific issue but either way, why do you need to care if the IDE warns about it? the project still imports into and builds in the IDE without any problems, and Gradle builds are not affected

there's an IDE plugin to hide this specific error if it really bothers you, <https://plugins.jetbrains.com/plugin/18949-gradle-libs-error-suppressor>

I prefer to use
```@Suppress("DSL_SCOPE_VIOLATION")
plugins {
  // ...
}```
Thanks everyone.

I care because when there's an error people look at it.
An error has to be fixed, and if it is a false positive the correct fix is a suppression with comment explaining why it has been suppressed

I still wonder why the official gradle documentation doesn't even have an example of how to use it in a plugin (using `alias`)

it does, <https://docs.gradle.org/current/userguide/platforms.html> example 10

gradle ~is~ _would be_ great _if the documentation was better_

&gt; _Example 10. Using a plugin declared in a catalog_
I see, I was looking for it but missed it.

I find Gradle is well documented, especially relative to other build systems of similar complexity. the problem is often finding the right documentation. I know some people have been writing *targeted* blog posts matching keywords that people are searching for, to help steer Google traffic to the right place. however in this case, a search for "gradle version catalog plugin" already leads to that as the top result

&gt;  gradle ~is~ _would be_ great _if the documentation was better_
I can fullheartedly disagree here.
Gradle has amazingly good documentation.
Especially compared to many other tools.
Imho the documentation of course has potential for improvement as anything, but all-in-all I quite like it.
If you have specific improvements in mind, open issues or prs about it so the Gradle guys can consider it.

the thing is, I believe, it misses some getting started that actually get you the tools to know what you are doing and know where to find what you need.
I've to read A LOT of documentation to know what to do.
Maybe you are right, the documentation is good. But it is overwhelming and requires a deep dive to actually know what to do.

Most developers just want to build their app, they don't want / have time to dig deep into how gradle works.

I know I'm not alone thinking this. And don't get me wrong here, when I do learn how to do stuff I think gradle is great. I just wish it was a bit more beginner friendly. I've been using gradle for years now and I still don't know how to achieve a lot of stuff.
Kotlin DSL helped me with the discovery (autocompletion) in the last year I've to say.

I'll think about it if I can come up with some specific pointers on what I think could be different / improved

There is a getting started page and there are also example projects and tutorials, there is not only the user guide in case you missed it. :slightly_smiling_face:

I went through those long time ago, when android switched to Gradle. And they weren't that helpful back then. I'll check them again.

&gt; Gradle is a flexible and powerful build tool that can easily feel intimidating when you first start.
this wasn't there before, but it surely describe my first approach to it :slightly_smiling_face:

yes getting started is A LOT better than I remembered it to be, I think it's worth going through it even if I'm using gradle for a long time now

Is there a reason why publishing is separated into a separate CI task?  Generally it needs to know a whole lot of configuration/context, overlapping with how artifacts are built, dependencies, etc.

Well, yes, this is a release pipeline, I want to build first, then test, then upload. If the test fails I’d otherwise have to delete the upload, because our prod repo cannot upload identical artifacts again (company policy).

the Gradle build cache can possibly help here - publishing would look at all the dependent tasks and have the build cache results satisfied, thereby not needing to run them again.

Gradle build cache is in place and doesn’t help. Just did the experiment - I kept all of &lt;mymodule&gt;/build and cleaned the rest of the repo. Then I executed my publish task again, and still, my app was compiled again.

build cache is stored in `~/.gradle/caches/build-cache-1`.  Running with `--info`will indicate, for each task, why it wasn’t up-to-date.

If you wish to change the location:
```buildCache {
    local {
        directory = File(rootDir, "build-cache")
        removeUnusedEntriesAfterDays = 30
    }
}```

Given your setup, my recommendation would be to take a slightly different approach:
• In your build, use `maven-publish` to push to a local repository
• In the following step, publish the content of the local repository to your remote repository. This however would have to be done outside of a Gradle build. That is `maven-publish` is not designed for this.

Especially since I really only have to take over the artifacts from one build onto the other that are uploaded, not any other intermediate cruft. This speeds things up as well!

We have a settings.gradle.kts and we have a plugin that does a tiny bit of setup
```plugins {
    id("com.us.our-plugin") version "version"
}```

Unfortunately no (AFAIK), at least not with `alias()`.
But you might be able to use the TOML from a `buildSrc` (or included build) and then use the plugin without version:
```plugins {
    id("com.us.our-plugin")
}```

Wasn't able to get alias working unfortunately, and also not able to get buildSrc working

Included build is working, but not from the classpath, I have to manually create a new plugin with the
````java-gradle-plugin````
plugin, then register a new plugin.

So yeah 2 bits of strangeness. api/implementation doesn't matter, the plugins aren't loaded. Also buildSrc strait up can't register a plugin that the settings.gradle file will load.

So we were able to get it to work (super ugly) by moving from buildSrc to includeBuild, and from creating a new gradle plugin whose implementation was just the same as the plugin that we already had a dependency on.

Alias will not work due to hen-and-egg.
Settings plugins should be able to bring in version catalogs, so you cannot use version catalogs before the settings plugins were applied.

And `buildSrc` will also not work, it was long ago that `buildSrc` was evalutated before settings script and could be used therein, nowadays settings script is evaluated first so `buildSrc` things cannot be used.

Included build in `pluginManagement` with an actual settings plugin (even if it does not do anything) in it that is applied should work, as you found out.

Or you can use a TOML parser to parse the TOML file "manually" and use the version of the plugin you want to apply.

Thanks <@URQ797WRW>, this is new to me 'nowadays settings script is evaluated first'

Do you know why plugins included via dependencies in includeBuild aren't available to settings.gradle?

And I have to
```dependencies {
    implementation(libs.our.settings.plugins)
}
gradlePlugin {
    plugins {
        register("settingsPluginHack") {
            id = "our.settings-plugin"
            implementationClass = "our.gradle.SettingsPlugin"
        }
    }
}```

Where I have to re-declare a plugin with id

Including a build does absolutely nothing as long as you don't need something from the included build.
In this case, if you don't use a settings plugin from that build, it (and its dependencies)  are not added to the class path.

&gt; don't need something from the included build.
How do you specify a need? Other than the gradlePlugin block

Or is that/the convention plugins the only way?

For that case I think it is the only way.
For build scripts you could also use `buildscript { dependencies { ... } }`

does that buildscript go into the includeBuild's build.gradle? Or in the root settings.gradle?

Instead of redeclaring the plugin you could write a simple no-op pre-compiled script plugin, just to drag the dependencies to the class path

I said "For build scripts you could also use"

If you want the classes of an included build available in a build script without applying a plugin from that included build

what do you mean by no-op pre-compiled script plugin?

A precompiled script plugin that has no content and thus is no-op(eration).
You just apply it to drag in the transitive dependencies.

Looks like a permissions issue in the noted folders.

Make sure your user account is able to create directories there.

And please don't split messages about several threads, that makes it very hard to follow the conversation in the threads view. If you have additional information, either edit the original message or post to its thread.

And btw. if you are going to hit a flutter-specific issues, there is als <#C03EM93810S|>

There are a number of suggestions on this StackOverflow post that may be helpful: <https://stackoverflow.com/questions/38810668/gradle-sync-failed-failed-to-create-parent-directory>

Ok guys i will keep all these small details in mind and thanks for providing the solutions

Given the older jvm / gradle it's possible that your repo only supports tls 1.2 for https (as it should) but jvm / gradle are unable to negotiate tls version (or perhaps ciphers).  AFK atm to lookup jvm tls debug property to show more details.  If possible run a newer Gradle version on a newer jvm (version 11 or 17 for LTS), using tool chain for compiling at Java 8.

ok,tkx,i can't upgrade jdk version,but i can upgrade gradle version，i will be try upgrade gradle 7.5

The TLS handshake is at the JVM level, not inside Gradle.

should be able to update the JVM and use Gradle toolchain (in newer versions of Gradle) to still compile on JDK 8 (where Gradle itself would be running on Java 11 or above).

The only I can think of is the Jacoco one, also core Gradle.

But it probably has the same internal complexity. Variants are really powerful for this but also quite complex to leverage for now.

If you find some, please point them out. Would be interesting to see what kind of APIs Gradle should provide to make their implementation easier.

I think <@U023HSZL88M> has one and <@UMD8Q0MBL> was playing with that concept too but not sure if his projects are open source 

This is what I have and I think this is kind of a minimal example (+ I have some explanation :slightly_smiling_face: )
<https://github.com/jjohannes/understanding-gradle/tree/main/13_Aggregating_Custom_Artifacts>

script is setting a property multiple times, likely one of those is during task execution which is not allowed.

thank you for replying. How do i know which value? this code was working fine until i upgrade react native version.

perhaps track it through the full stack trace to where it’s being set

please add that as a file, not separate messages, very hard to follow.

gradle error stacktrace

Also am using this script to build and publish the release
```"android-release": " yes | sdkmanager --licenses &amp;&amp; cd android/ &amp;&amp; ./gradlew publishRelease --stacktrace",
    "android-bundle": "react-native bundle --platform android --dev false --entry-file ./index.js --bundle-output ./android/app/src/main/assets/index.bundle --sourcemap-output ./android/app/src/main/assets/index.map --assets-dest ./android/app/src/main/res/",
    "android-pre-release": "npm run android-clean &amp;&amp; npm run android-bundle",```

The below show what property is being set and who is setting it at execution time:
```&gt;&gt;&gt; property being set: at com.android.build.gradle.[MASKED].api.ApkVariantOutputImpl.setVersionCodeOverride(ApkVariantOutputImpl.java:96)
	at com.android.build.gradle.[MASKED].api.ApkVariantOutputImpl_Decorated.setVersionCodeOverride(Unknown Source)
&gt;&gt;&gt; calling code that is setting it: at com.github.triplet.gradle.play.tasks.ProcessArtifactMetadata.process(ProcessArtifactMetadata.kt:33)```

yes thank you for finding it. I already suspected that and couldnt find a solution for it till now.
```applicationVariants.all { variant -&gt;
        variant.outputs.each { output -&gt;
            // For each separate APK per architecture, set a unique version code as described here:
            // <https://developer.android.com/studio/build/configure-apk-splits.html>
            // Example: versionCode 1 will generate 1001 for armeabi-v7a, 1002 for x86, etc.
            def versionCodes = ["armeabi-v7a": 1, "x86": 2, "arm64-v8a": 3, "x86_64": 4]
            def abi = output.getFilter(OutputFile.ABI)
            if (abi != null) {  // null for the universal-debug, universal-release variants
                output.versionCodeOverride =
                        versionCodes.get(abi) * 1048576 + defaultConfig.versionCode
            }

        }
    }```

not following the specifics but would try and avoid calling .get() on properties during the configuration phase.  This may mean using property.map { your logic here } to create a derived provider that is then used.

you’ll need to review where that whole code snippet is called from, as `output.versionCodeOverride =` is the culprit, may need to call this code sooner.

that part of code was working normally until recently. It is mentioned here in the react native template
<https://github.com/facebook/react-native/blob/main/template/android/app/build.gradle#L246-L257>

if found something else, my gradle config still works with react native 0.63.4 but with 0.67.4 is failing.
still looking for a solution, any ideas?

<@U02S31Y7J2K> thank you for helping, unfortunately i still didnt find any solutions yet. can you help me debug this again ?

How about a simple google search / GitHub search for the problem?

<https://github.com/Triple-T/gradle-play-publisher/issues/809>

<https://github.com/Triple-T/gradle-play-publisher/issues/790>

i wish it was that simple. found that also, but the issue is mentioned as fixed. also tried upgrading to 7.4 and downgrading to 6.9 and still same issue. Am i missing something

What version of that plugin are you using?

```   dependencies {
        classpath("com.android.tools.build:gradle:4.2.0")
        // classpath "com.android.tools.build:gradle:3.5.0"
        classpath "com.github.triplet.gradle:play-publisher:2.4.1"
        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }```

What's your question then?
You are using 2.4.1, but the error is fixed for 3.0.0

ok let me explain, i retried again with v3.0.0 until v3.4 with agp 4.1, 4.2 and followed the releases published for play-publisher, and got other type of errors like
```Failed to notify project evaluation listener.
   &gt; java.lang.StackOverflowError (no error message)```
would be great if we can check it together

Maybe better check together with the developer of that plugin?
I'm not even an Android developer and also never heard of that plugin.
I just found it from your stacktrace and a quick search.

exception.txt

the project is a monorepo composed of several independent projects

it is built using kotlin dsl and the source code for each project is kotlin

the gradle build creates a “fat” jar for several projects and this apparently makes the report generation `testCodeCoverageReport` task fail with the exception in the file

I can’t seem to find a way to fix this issue without making the JAR files “slim”, but if I do that, the JAR files won’t find the classes of the other dependencies that come from other subprojects of the monorepo

so basically the “fat” JAR allows for having projects within the monorepo with dependencies on other subprojects of the same monorepo

Can you show the list of tasks that are being executed when you run this task? I haven't used jacoco too extensively but from a quick glance it should run on class files not jars. If you running the jacoco and tests against a fat jar, it will include the test coverage of your dependencies, which I don't think you really want.

The jacoco task also supports includes and excludes so you can try to exclude packages you dont want (kotlin.reflect.*) and include only things which match your package structure. 

<https://docs.gradle.org/current/userguide/jacoco_plugin.html|https://docs.gradle.org/current/userguide/jacoco_plugin.html>

I did a `gradle clean test` the task execution order is this:
1. `clean`
2. `test`
3. `testCodeCoverageReport` 
for each subproject

I believe it is running the report against the jar files

I have tried to make it run the report against the classes instead but without success

The test tasks must call things like compileClasses, etc. Can you send the full list? I'm curious if jar will be in the list of tasks excited.

gradle_build.txt

this are all tasks being executed:
1. `clean`
2. `compileKotlin`
3. `test` 
4. `jar`
5. `testCodeCoverageReport` =&gt; fails
6. `testCheck` =&gt; custom task fails too because of no. 5 failing
This is the rest of the output that goes before the exception is thrown:

not sure if this helps, but I customized the jar task for that subproject to modify the manifest main class and other properties

it was the only way I got it to produce a JAR that would run a main Kotlin function

I don't think the jar task should be in that task graph. Do you have anything custom in a build script to add that as a dependsOn, finalizedBy relationship or maybe linked via Inputs/Outputs? 

Modifying the jar task like you have done sounds absolutely fine, but I don't think jar needs to be executed as part of this workload.

it is not defined as a finalizedBy or dependsOn task to any other tasks

could it be the jacoco `testCodeCoverageReport` task that dependsOn the `jar` to create the test coverage reports?

it has been hard for me to find any examples of the plugin for kotlin dsl to specify use of classes instead of jars

Are you able to toss a sample project up on GitHub with your exact builds scripts and some dummy project code? I'll gladly check it out and see what I can come up with.

that would be awesome thanks :thumbsup: I’ll try to get one pushed

<@U03DCP95VFY> I have just finished setting up an example repo <https://github.com/aros88/gradle-multiproject>

you should be able to reproduce the error by doing `./gradlew test --stacktrace`

Really appreciate any help you can give :thumbsup: thanks beforehand

<@U03GJ0URGGL> quick question. Do you need a runnable jar, or would something built from the application plugin work as well? What is going to be running this code?

hey, I need a runable jar, it will run inside a docker container

The application plugin can build you a zip or a tar file, which also comes with preconfigured shell scripts to handle running the application for you. Would you be open to running your code via the shell script instead of a "java jar" CLI command?

yeah, as long as it gets the same results, i.e. runs the main function, I would be okay with that

Hope you don't mind but I've taken quite the liberty in cleaning up and refactoring the build scripts. I'm about to open up a pull request. Jacoco works fine for me now and the application works too.

awesome, I don’t mind at all! that is great news

Here you go! 

<https://github.com/aros88/gradle-multiproject/pull/1|https://github.com/aros88/gradle-multiproject/pull/1>

The main thing is removing the fat jar stuff and replacing with application plugin. The convention plugin stuff just cleans things up but is not necessary by any means.

hi <@U03DCP95VFY> I was checking out the PR, thank you so much for the refactor, I have learned a lot about gradle just by reading it

the `testCodeCoverageReport` is not failing anymore which is great

but there seems to be an issue with the aggregation process of the jacoco report, it only includes the classes of the last project to be built and tested

in the sample project case, it was not showing because `project-b` had as dependencies all others in the repo, but if you remove for example `lib-a` from its dependencies, it stops showing in the aggregated `index.html` as can be seen in the picture

I am not sure if its possible to have all subprojects show in the report regardless of whether they are dependencies being used or not. I thought that is what the `jacoco-report-aggregation` plugin was supposed to do

you appear to be confusing different types of properties.

System (Java) properties, if they start with `org.gradle.project.`, are added as Gradle properties to the project (without the prefix)

environment variables, if they start with `ORG_GRADLE_PROJECT_`, are similarly added as Gradle properties to the project (without the prefix)

System properties can be set with `./gradlew -D...` or similar through JVM options; Gradle properties can be set with `./gradlew -P...` or `gradle.properties`

so there is no need for the prefix on Gradle properties; you just need it on system properties if you want to use that mechanism to set Gradle properties

there was a recent blog post about this: <https://www.liutikas.net/2022/04/25/A-Bag-Of-Properties.html>

<@U019L3NM4PK> Thank you for explaination :slightly_smiling_face:
Now i get it.
`-Dorg.gradle.project.foo=bar`will work the same as `-Pfoo=bar`

not relevant. they're only enabled with the compiler option `-Xcontext-receivers` and aren't ABI stable yet

I can't use them to build Gradle plugins right now because Gradle is not using 1.6.21

and you can't use them to build Gradle plugins after Gradle uses Kotlin 1.6.21 either, is what I mean

When Gradle starts to use 1.6.21, I can use them and they should work same if I was in a normal project?

Okay, looks like Gradle 7.5 should use Kotlin 1.6.21 but RC is already published and it is still using 1.6.10 I think

So maybe it has been delayed to 7.6 or 8.0?

I don't know, but even with 1.6.21 it won't be usable