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

Gradle Community

Hello, is it possible to access `RootProjectAccessors` within any file in `buildSrc` just like version catalogs?

Property is the right way.
You can only inject into the constructor what is an injectable service by Gradle.
But I'd use
```abstract val jvm: Property&lt;Boolean&gt;```
Dunnot what `Delegates.notNull` does.

I'm using `jvm` to return the corresponding `targetDir` later on
```@get:Input
abstract val jvm: Property&lt;Boolean&gt;

@get:OutputDirectory
val targetDir: DirectoryProperty
    get() {
        val platform = if(jvm.get()) "jvm" else "nonJvm"
        val dir = project.layout.buildDirectory.dir("generated/$platform")
        return project.objects.directoryProperty().convention(dir)
    }```
```val generateJvmCode by registering(GenerateCode::class) { jvm.set(true) }
val generateNonJvmCode by registering(GenerateCode::class) { jvm.set(false) }
kotlin.sourceSets {
    named("jvmMain") { kotlin.srcDir(generateJvmCode) }
    named("nativeMain") { kotlin.srcDir(generateNonJvmCode) }
//    named("jsMain") { kotlin.srcDir(generateNonJvmCode) }
}```
however, on sync:
&gt; com.intellij.openapi.externalSystem.model.ExternalSystemException: Could not create task ':generateJvmCode'.
&gt; Could not create task of type 'GenerateCode'.
&gt; Cannot query the value of task ':generateJvmCode' property 'jvm' because it has no value available.
is a dependency between properties allowed?

solved this way
```abstract class GenerateJvmCode : GenerateCode(true)
abstract class GenerateNonJvmCode : GenerateCode(false)

abstract class GenerateCode(
    @Internal
    val jvm: Boolean): DefaultTask() {```


```
@get:Inject
abstract val layout: ProjectLayout

@get:Input
abstract val jvm: Property&lt;Boolean&gt;

@get:OutputDirectory
val targetDir = jvm.flatMap {
    val platform = if (it) "jvm" else "nonJvm"
    layout.buildDirectory.dir("generated/$platform")
}```


is it mandatory for `layout` to be extracted into a property itself?

No, but it is better to inject it and use it than to use `project` usually.
Accessing `project` of a task during configuration time is ok, during execution time it is deprecated and will be forbidden.
So better to simply avoid using it whenever possible.

I have asked my self the same thing for `api`  and in a small test I did, it seemed to work: the platform was also used for dependency resolution of dependencies added to `api`
But I didn't find any documentation about it either.

Hi, check <https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_plugin_and_dependency_management> (Fig. 3) and <https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_configurations_graph> for a view of the hierarchy of configurations.

Afaik a platform added to a configuration is inherited to the configurations extending from it.
So in this case a platform applied to `implementation`  also applies to `testImplementation`

But this wouldn't explain why a platform applied to `implementation` also applies to `api`, so I think there might be a bit more happening

`api`  itself might not be resolved itself at runtime, but rather `compileClasspath` /`runtimeClasspath`  - which would see the platform from `implementation` . But I might be wrong about that...

btw, is there any reason to use `io.spring.dependency-management` if using `enforcedPlatform`? It seems they have same purpose.

Have a look <https://github.com/spring-projects/spring-boot/issues/29588|here> for potential reasons to keep using the dependency-management plugin

We recently switched from `io.spring.dependency-management`  to using platforms, no looking back.
I wouldn't mix both...

While the Spring folks' point in the issue about convenience of simple version override for the dependency groups still stands (even if we found it not a serious issue for us) performance degradation on resolving somewhat a hundred detached configurations in a simple project is a strong point against using the plugin.

you should apply the convention in the plugin that creates an instance of the extension

the extension itself should be as "dumb" as possible and not be aware of any defaults that might exist for the plugin

so, like this
```val setting = project.extensions.create&lt;MagikExtension&gt;("magik").apply { 
    commitWithChanges.convention(false)
}```
and this will be set before the user may set anything in its own?
Also, shall I ditch `Properties` for plain primitive? I'm quite tempted to do so..

I'd just go with `setting.commitWithChanges.convention(false)` . Seems more straightforward to me.
Properties give you the possibility for lazy evaluation. Wherever you use the extension properties, you should link them to a task property, so that they're only evaluated when they're actually being used. Aka during task execution and not earlier.

note that I don't think you're supposed to add annotations like `@get:Input` on an extension, as extensions technically don't have any inputs or outputs, they're just a bucket of configuration values. It's the tasks that have inputs and outputs. I might be wrong on that point though.

Iirc you could use the extension as `@Nested` input on a task and then the annotations on the extension would be relevant. But you really shouldn't do that, but linke the individual properties together.

After inspecting the classpath, it turns out I use Kotlin 1.6 with 1.7 plugin :sweat_smile:

You can get them from the settings using `val foo: String by settings` or its "extras" with `extra["foo"]` (assuming Kotlin DSL here, with Groovy DSL I think you can just use `settings.foo`).
But you may want to prefer `credentials(PasswordCredentials::class)` after naming your repository: <https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:handling_credentials>

Yeah both
`extra["FOO"] as String`
`val foo: String by settings`
Seem to work. Trick being that you need to be explicitly casting it to a String, which should be safe anyway.

Interesting, didn’t know about the PasswordCredentials, seems a bit more magic there, like it expects the keys to read exactly `{name}` plus `Password`|`Username` suffixes.
Meaning the key can not be `SOME_THING_PASSWORD`  but would need to be `SOME_THINGPassword` or maybe even `someThingPassword`.
Not the end of the world I guess.

Would just look odd in my Github Secrets next to everything else which is capitalized snake case

Here is wiremock build.gradle
```plugins {
    id 'java'
}

repositories {
    mavenLocal()
    maven {
        credentials {
            username nexusUsername
            password nexusPassword
        }
        url = '<https://nexus>.***.com/content/groups/private'
    }
}

dependencies {
    testImplementation("com.github.tomakehurst:wiremock-jre8:_")
    testImplementation("org.testng:testng:_")
}```
And here is build.gradle from another project added the same way, that works.
```plugins {
    id 'java'
}

repositories {
    mavenLocal()
    maven {
        credentials {
            username nexusUsername
            password nexusPassword
        }
        url = '<https://nexus>.***.com/content/groups/private'
    }
}

dependencies {
    implementation("com.sun.mail:javax.mail:_")
    implementation("org.jsoup:jsoup:_")
    testImplementation("junit:junit:_")
}```

Did you only configured the `project().projectDir` and forgot the `include()`?

:face_palm: I was starring at it the whole day and answer was in front of my eyes the whole time!

Thank you <@UDC9Q9RD0>
This is it!

pro-tip: add a new line between the `include` and `project` lines :wink:

Iirc, the problem is not, that you have two plugins blocks.
The problem is, that you ahve one plugins block within a script plugin.
Script plugins do not support the plugins block but can only apply plugins via legacy `apply` method.
One of the reasons amongst others why legacy script plugins are bad and should be avoided.
I would indeed recommend to make it a precompiled script plugin instead.

Thank you for the answer. That explains quite a bit and seems logical looking at some docs and SO posts.

Seems I will do that then and see where that brings me! Thanks for the help!

I was testing out repeated builds to see what tasks aren’t properly cached and saw this one. We use the cache-fix-plugin and it appears `org.gradle.android.workarounds.RoomSchemaLocationWorkaround$RoomSchemaLocationMergeTask` isn’t cacheable? We use the recommended room settings from the cache fix plugin’s documentation.

Ah, `Logging.getLogger(...)` gives me the `Logger` I need.

He has, using component metadata rules for cases where the dependency did it wrongly as work-around.

could you point me toward some more info about it, please?

<https://docs.gradle.org/current/userguide/component_metadata_rules.html>?

I did (don't have the code with me now), and it's been working for many years. I didn't use any of those plugins, just jacoco.

I didn't configure jacoco for UI Test

Was it also an Android application project? I guess it was not Kotlin back then?

Did anyone use <https://github.com/NeoTech-Software/Android-Root-Coverage-Plugin>?

Configuration is a `FileCollection` so you can set it to an input of your task during task … configuration (lol)

Also, what is the use case for this, above code looks like abuse of APIs (though I cant really say why it feels like that to me)

This is an actual example from Gradle docs regarding dependency locking, just that I copied the code into the task itself

Seems like the Plugin Portal is having issues due to JCenter being down at the moment, plugin deps failing to resolve here as well

it happens for many other plugins as well
.. strange that it was wokring and now suddenly out of blue everything is broken without doing any changes in our code

Sure it is still running. It will not be switched off. Just another of is outages. I thought Grape or up an own mirror though, but I might misremember.

but why can't gradle plugin repo redirect / proxy to mavenCentral instead since it is now the recommanded default repo?

It always was the canonical and more stable repo. I'm not aware of anyone recommending JCenter as default repo and if, then it was imho a bad recommendation.

But you probably cannot simply change that, as it would change behavior and break builds because dependencies suddenly resolve differently.

I m not sure what should we do know.. we are using quite few plugins which have transitive dependencies and they are trying to be downloaded from jcenter .. is it possible to override it somehow? we are basically stuck because of that and we cannot build anything

if change your plugin repositories to add mavenCentral() first, and your plugins/dependencies are available there, then it shouldn't hit gpp/jcenter

e.g.
```pluginManagement {
    repositories {
        mavenCentral()
        gradlePluginPortal()
```
in `settings.gradle`(`.kts`)

That doesn't seem to be working for me. I wasn't declaring any extra plugin repositories, but my builds started failing. And adding that didn't help.

this starts to be very critical and blocking, we need to find some WKA.. is there anyone from Gradle plugins repo maintainers? Or any way how to escalate this?

They are aware and also put some work-around in place minutes before your message: <https://status.gradle.com/|https://status.gradle.com/>

If the dependencies you need are available on Maven Central or Plugin Portal a client-side work-around was already mentioned above. If the needed dependencies are only available on JCenter, there is no client-side work-around, besides using a caching proxy like Nexus Repository Manager to be independent of such outages.

thanks, the work-around they introduced worked..
The work-around mentioned above didn't work (as <@UADCWN4H5> mentioned as well), it was still trying to download the transitive dependencies of a plugin via the plugin repo which was keeping redirecting to jcenter.
yeh, using a nexus proxy repo is definitely a good idea, we are using it for mavenCentral, but so far we haven't use it for gradle plugins repo

Hi! I'm still getting the error:
```What went wrong:
A problem occurred configuring root project 'backend'.
&gt; Could not resolve all files for configuration ':classpath'.
   &gt; Could not find com.sonatype.nexus:nexus-platform-api:4.0.0-01.
     Searched in the following locations:
       - <https://plugins.gradle.org/m2/com/sonatype/nexus/nexus-platform-api/4.0.0-01/nexus-platform-api-4.0.0-01.pom>
     If the artifact you are trying to retrieve can be found in the repository but without metadata in 'Maven POM' format, you need to adjust the 'metadataSources { ... }' of the repository declaration.
     Required by:
         project : &gt; org.sonatype.gradle.plugins.scan:org.sonatype.gradle.plugins.scan.gradle.plugin:2.5.1 &gt; org.sonatype.gradle.plugins:scan-gradle-plugin:2.5.1
   &gt; Could not find com.pinterest.ktlint:ktlint-core:0.47.1.```
The workaround <https://gradle-community.slack.com/archives/CAHSN3LDN/p1667180083300229?thread_ts=1667158392.069209&amp;cid=CAHSN3LDN|mentioned> didn't work as well.
I'm not sure what to try now. Any recommendations?

Maven Central work-around should work as it is present there. Try with `--refresh-dependencies` in case the resolution cache just has stale information.

No, still getting it. I'm running locally:
```$&gt; ./gradlew assemble --refresh-dependencies                                                                                                  

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'rillet-backend'.
&gt; Could not resolve all files for configuration ':classpath'.
   &gt; Could not find com.sonatype.nexus:nexus-platform-api:4.0.0-01.
     Searched in the following locations:
       - <https://plugins.gradle.org/m2/com/sonatype/nexus/nexus-platform-api/4.0.0-01/nexus-platform-api-4.0.0-01.pom>
     If the artifact you are trying to retrieve can be found in the repository but without metadata in 'Maven POM' format, you need to adjust the 'metadataSources { ... }' of the repository declaration.```

Also with the explicit "Maven Central"?
Without it, I think it will not work as they only mirror libs found directly in JCenter, not the ones JCenter forwarded to Maven Central.

yes, in the build.gradle.kts I have:
```repositories {
    mavenCentral()
}```

nexus-platform-api:4.0.0-01 is not in the plugin repo while ago there was just some older version 3.* and now there isn't any

&gt; yes, in the build.gradle.kts I have:
That is not the mentioned work-around.
You need to define it as plugin repository in your settings script, not as repository for your production code.

&gt; nexus-platform-api:4.0.0-01 is not in the plugin repo while ago there was just some older version 3.* and now there isn't any
There never was any.
The plugin portal redirects to JCenter for libs it does not have itself and JCenter forwards to Maven Central for libs it does not have.
But the server-side work-around put in place by the Gradle guys is just a JCenter mirror without the forwarding to Maven Central, thus it is currently not resolvable if you only have the plugin portal as plugin repository.

I thought they were equivalent. With that (and swapping some dependencies around) I have the build working again. Thanks for the help!

I think the gradle team needs to take issues like this more seriously. Every time this happens (and it happens a lot) they just throw their hands up, and throw the blame elsewhere, without ever realizing that builds being down is a major issue, and a build system that can’t build is useless. I’d like to see actual failure analysis done, and steps gradle can take to avoid these problems in the future. As much as they want to think it’s not their problem when this happens, everyone is going to blame gradle, as it’s gradle builds that break when this happens. 

What makes you think they just blame someone else and don't do anything?
That's not the case.
They majorly improved the situation the last time there was a longer JCenter outage and also in the meantime put up a stand-by mirror of JCenter to which they switched as a work-around currently.
They are very well aware this is a problem and are improving on it.

It always just seems like the first response is to say it’s just another outage, rather then we’ll look into it. That was definitely the case with past outages. And I’d like to see blog posts happen after the fact explaining what happened, and how gradle is working to mitigate the issues in the future. 

Like I had no clue that they started adding a mirror after last time, because they never did a post mortem for the last failure (at least a public one). It’s good that they are, but it seems like the stand by mirror maybe should be the default, rather then waiting for jcenter to break. Especially if it happens in the middle of the night, like normally seems to be the case, and it takes hours for someone to flip the switch to the mirror. With jcenter being read only, it seems like it’d be really easy to make sure the mirror always works, since there would never be any package update to it. 

I actually agree with <@UADCWN4H5>. I just didn't want to be the one to complain, but I was about to say basically the same.
I've convinced our company to migrate from maven to gradle based on the recent hype (and yes, I m still convinced it has certain advantages, especially when using Kotlin DSL), even our legacy monolith enterprise apps with 40+ subprojects and many dfiirent customer dist builds are now converted, I spent months on it.
And now, when it gets down I get it back in my face from my colleagues. I know the product is free for use etc. And I really enjoy using it most of the time, but it is hard to have some critical system based on it, especially when using its plugins, when it might happen that its primary plugin repo might stop providing plugin dependencies. Maybe the dependencies of each published plugin should be just stored on <http://plugins.gradle.org|plugins.gradle.org> server and not delegate anywhere else? I don't know.
It actually didn't took only hours, but almost 2 days, our build were failing already on saturday night and it only got fixed today. :neutral_face:

&gt; It always just seems like the first response is to say it’s just another outage
I'm not affiliated with Gradle, just sharing my experience.
&gt; That was definitely the case with past outages. And I’d like to see blog posts happen after the fact explaining what happened, and how gradle is working to mitigate the issues in the future.
<https://blog.gradle.org/plugins-jcenter>
&gt; Like I had no clue that they started adding a mirror after last time, because they never did a post mortem for the last failure (at least a public one).
Not true, see above

Hey folks,

we have been working on reducing the impact of the JCenter outage. <https://status.gradle.com/> contains updates.

And yes, severing ties with JCenter fully is complicated and will take time.
And will most likely break builds when it happens. We will communicate clearly whenever that is about to happen.

are there still issues with plugins/jcenter? We're just starting to see this in our CI

You don't show the full error. The ones you are showing just say "skipped due to previous error". But I guess this is because of the current JCenter outage: <https://status.gradle.com/|https://status.gradle.com/>

Thanks <@URQ797WRW> so much, I have read it, just confuse about the finish time that
```Oct 31, 2022 - 07:07 UTC```

It's not a finish time, it is an update time. And they wrote their work-around helps some, so maybe your are part of the others.

Let me know if there's a better channel to post this in.

not sure where this belongs, so this works :slightly_smiling_face: I need to explore this some more and will get back to you.

<@U03AFQVC16K> this might be helpful? <https://mastodon.social/@TomEtty/109263817611325574|https://mastodon.social/@TomEtty/109263817611325574>

Thanks for the extra information!  Considering the followers for <https://twitter.com/AndroidDev|AndroidDev> for twitter are 2.1 million but only 273 for mastodon it doesn't seem like it is quite worth the resources just yet.  I made a reminder to look at this again in 3 months, if there is significant growth from the mastodon then I can petition for some resources to get this set up.

I believe it wouldn't, but I wouldn't swear it.

AFAICT, com.intellij:annotations was the old name of org.jetbrains:annotations. You could/should use a module replacement rule to tell Gradle about this and avoid this duplication: <https://docs.gradle.org/current/userguide/resolution_rules.html#sec:module_replacement>

That being said, com.intellij:annotations:12.0 is very old (<https://search.maven.org/artifact/com.intellij/annotations>, almost 10 years old), as is version 13.0 of org.jetbrains:annotations btw (<https://search.maven.org/artifact/org.jetbrains/annotations>, 9 years old), so you might want to use the `dependencyInsight` task to understand where they come (<https://docs.gradle.org/current/userguide/viewing_debugging_dependencies.html#sec:identifying_reason_dependency_selection>) from and possibly have them upgraded upstream (or yourself upgrade some dependency that transitively depends on them)

fingerprinting is taking the task inputs and creating a hash value of them for later comparison (to determine if anything has changed).  The number of inputs (e.g. number of files) and perhaps the size of files are common suspects for slow fingerprinting.

other common causes include slow disks (perhaps a network share), or anti-virus software that is intercepting each file read

Could you share a screenshot of Performance &gt; Build for that build? Also a screenshot of the timeline would be helpful.

Also, do you have `maxParallelForks` configured for your test tasks?

<@U042816HVD0>
More context: Our android app is hybrid with react native. When building the app, RN has a task to bundle all the JS files(task name: "bundleReleaseJsAndAssets" as seen in the screenshot)

Below are the tasks and respective number of input files
app:bundleReleaseJsAndAssets → Number of Input files are around 108396. [lot of js files]
module2:packageReleaseAssets → Input files are around 22 [primarily xmls, .kt files]
module3:mergeReleaseShaders → Input files are around 57
module4:mergeReleaseShaders → Input files are around 44
module5:mergeReleaseShaders → Input files are around 22
module6:mergeReleaseShaders → Input files are around 562
module7:packageReleaseAssets → Input files are around 32
module8:packageReleaseAssets → Input files are around 38

no maxParallelForks is not configured in our project

Thanks. In addition to what <@U02S31Y7J2K> said above, high memory usage and garbage collection times can also contribute towards long fingerprinting times. Based on the screenshot of your performance tab this could also be a culprit.

Hey <@U042816HVD0> Thanks for the previous inputs. Got some more info around this.
After checking couple of other gradle scans, I found out that higher fingerprinting input doesn't happen when *bundleReleaseJsAndAssets* runs before the other merge resource tasks. Basically issue happens only when *bundleReleaseJsAndAssets* runs parallel with other merge resource tasks.
Attached Timeline and Performance screenshots. Also the memory consumption and garbage collection time are in similar range for both scans.

<@U042816HVD0> Any input for this would be very much helpful!

It's my pleasure! :blush:

Very interesting observation. It still could be caused by resource contention in terms of available threads. Do you know if `bundleReleaseJsAndAssets` is creating multiple threads to perform its work? I am not very familiar with that task.

from above, that task has a huge number of input files:
&gt; app:bundleReleaseJsAndAssets → Number of Input files are around 108396. [lot of js files]
Could be various forms of resource contention:
• CPU exhaustion; worth viewing a CPU usage timeline to match up with task execution;
• Snapshot contention; perhaps there are internal Gradle locks or other areas of contention magnified by large volume of snapshotting.  The <https://docs.gradle.org/current/userguide/performance.html#low_level_profiling|Gradle Profiler> may help here.
• while garbage collection isn’t wonderful (50s of GC is not good), that doesn’t fully account for the observed delays.   Perhaps review the memory sizing - does the running host have enough physical memory (without swapping) for what appears to be a 10GB heap?  Does increasing the heap size (to say 12GB) materially change the performance profile?

Oh, and of course thread contention (or exhaustion) as mentioned above.  May require a review of how that task is implemented and/or profiler analysis.

<@U042816HVD0> <@U02S31Y7J2K> Thanks for the inputs. Let me check if the task is creating multiple threads. Also let me try increasing the heap size and check the performance!

Modify the test case to not print to stderr?

it is third party code that prints to stderr which I cannot change

effectively, I’m interested in using a gradle project to compose other gradle projects - rather than write shell scripts or something that isn’t gradle

perhaps have ProjectA publish an artifact to maven repo (which would include versioning, dependency metadata) and have ProjectB consume it?

&gt; perhaps have ProjectA publish an artifact to maven repo (which would include versioning, dependency metadata) and have ProjectB consume it?
this is what `./gradlew assembleArtifact` does

is the issue then having to build everything together?  If they’re already decoupled via publishing, why do they need to be built together?

&gt; is the issue then having to build everything together
yes. this issue is about avoiding a custom scripting tool and being able to leverage Gradle instead of say  <https://fastlane.tools/>

I have a custom job where I build a downstream app and our internal SDK together, I would like this to be a gradle task

To get that capability in Gradle you could use a custom Gradle task that either executes another Gradle build, or uses the Tooling API.  Or a shell script to run both (publishing to mavenLocal, for example).  Or a CI job that does something similar.  Or rethink the coupling on SDK and consumer.

yeah I’m adding a new gradle project that does:

```execOperations.exec {
    commandLine(
        "./gradlew",
        ":assembleArtifact",
        "-Ppublish.version=$version"
    )
}```
Just kind of wild to have 3 gradle daemons

yea.  a bit of a smell.  seems like those tasks should either be decoupled, or at a minimum handled outside of Gradle.

I would probably use the tooling API to trigger other builds, not `exec`. I'd say it is at least a bit cleaner. :-)

And to answer the initial question, no. Included build always run in the same daemon and with the same Gradle version the including build is using. There is no way to change that besides waiting for my feature request ticket to be resolved. If the two build use incompatible Gradle versions, composite builds cannot be used.

could you share that feature request? I’d love to have fully isolated builds within the same daemon

Are you sure `GradleBuild` will run within the same daemon?

the daemon is typically limited to doing one build at a time (occasionally see “daemon is busy, starting a new daemon” messages or somesuch.

The feature request was actually not mine, it is <https://github.com/gradle/gradle/issues/8246>

&gt;  the daemon is typically limited to doing one build at a time
That's the source of my doubt :smile:

So, just to clarifiy I’m using a third gradle project to compose two projects
• first project (owned by me) publishes an Sdk
• second project (a downstream app, not owned by me) consumes that Sdk
This 3rd project that composes the two
• owned by me, so it could be merged with the first one.
• it builds the downstream app with my sdk
If `GradleBuild` stays isolated, then I could use it. But the downstream app internally uses composite builds, as does my sdk. So that might be a blocker?

perhaps change the third gradle project to a simple script.  Lots of Gradle overhead just to sequence two things.
• &lt;in SDK project&gt; ./gradlew buildAndPublisSdk
• &lt;in downstream project&gt; ./gradlew consumeSdkAndDoAmazingThingsWithIt

Does the tooling API provide more efficient access to task output? I have no idea where to get started with that tbh.

&gt; access to task output
I’ll be building APKs, and would probably want to copy them into the build directory of my 3rd composing project. Obviously could do this with a `CopySpec`, but there might be something more efficient then executing a `./gradlew buildApk` command every time, and copying

&gt; Lots of Gradle overhead just to sequence two things.
It’s actually fairly complicated. I’ll have logic to build the downstream app from our SDKs source, from artifactory, from a git branch. And that downstream app may be a local copy, or a git commit that would be checked out insolation.

&gt; perhaps change the third gradle project to a simple script
I’d like to write all this logic in kotlin, which Gradle supports well - and other developers on my team are familiar with Gradle, so there’s benefit there.

And after all, it is _build_ logic. it just gets weird with all the combining of gradle builds/daemons

could consider removing permutations; instead of
&gt; build the downstream app from our SDKs source, from artifactory, from a git branch
…build the downstream app from a versioned artifact (pass in version as a property), thereby decoupling producer from consumer.

&gt; agreed, same here…
But we were wrong actually.
I just tried and indeed `GradleBuild` runs in-daemon and thus has to be compatible with the same Gradle version.
Using the tooling API, it always runs in a separate daemon and by default uses the Gradle version defined in the wrapper files, so better for unknown sub-builds.

&gt; If `GradleBuild` stays isolated, then I could use it. But the downstream app internally uses composite builds, as does my sdk. So that might be a blocker?
Yes, as I said, `GradleBuild` does not support running composite builds right now, see the linked issue above.

&gt; Does the tooling API provide more efficient access to task output? I have no idea where to get started with that tbh.
The tooling API is what IDEs also use, so generally said, everything the IDE can do, you can do in your build too, so I'd say yes, you can access task outcome better.

&gt; …build the downstream app from a versioned artifact (pass in version as a property), thereby decoupling producer from consumer.
This is what I’m doing. I’m just using that 3rd Gradle project to effective compose these two calls:

```# from SDK - it publishes to a local maven folder
./gradlew assembleArtifact -Ppublish.version=99.99.99-SNAPSHOT

# from downstream app
./gradlew :downstream-app:assembleDebug -PSDK_VERSION=99.99.99-SNAPSHOT -PADDITIONAL_MAVEN_REPOSITORIES='/absolutePath/my-sdk/build/artifactory-publishing/artifacts/assembleArtifact' ```
And note, the above is simplified. I’m just trying to build some wrapper logic to make it all one step. It might include things like checking out a git repo in the future at a specific commit (or if the repo is already checked out, navigate to the desired commit)

&gt; runs in-daemon and thus has to be compatible with the same Gradle version
I am actually not too concerned with this being an issue, gradle seems to work well with transitively upgraded versions (outside of major version upgrades).

I would be concerned with with the plugins bleeding together:
• my SDK - on AGP 7.4
• downstream app - on AGP 7.1
And having the downstream app build fail bc it cannot be transitively upgraded due to a compiler error

I don't think the plugins should harm each other either way

But as I said, composite builds are not supported anyway and I doubt they will fix that soon.
So just use the tooling api. :-)

plugin versions are still fully isolated with `GradleBuild`? I guess it doesn’t matter with composite builds

this is a Kotlin question rather than Gradle

but <https://blog.mbonnin.net/kotlin-compatibility-quicksheet> should help

ah thanks, I asked here because I thought it has to do with my gradle library setup. Thanks for the link though!

Gradle doesn’t appear to directly offer that; you can fork tests for parallelism reasons (`maxParallelForks`), and for state-management reasons (`forkEvery`, for leaky tests or other state management issues), but not to my knowledge declaratively.

One workaround could be to define test groups / tags (depending on what  test framework is being used), and define two Test tasks configured appropriately.

I really just need

problemTestCase be executed before any other testcase in the system. That way i'm fine

If you want to solve that on the Gradle side, just define an additional test task that includes this test, exclude it on the normal test task and make the normal test task either `dependsOn`, `mustRunAfter`, or `shouldRunAfter` your custom task.

I'm what way should it respect or not respect it? The setting is not JaCoCo related.

tasks will run in parallel where Gradle determines it’s appropriate to do so.  Across project, and within a project (when configuration cache is enabled).  Is there something about these tasks that isn’t parallel friendly?  There isn’t a declarative way to ‘synchronize’, only a few hacky solutions depending on the nature of the challenge.

```execOperations.exec {
    commandLine(
        "./gradlew",```
I don’t want to spin up a new gradle daemon for each `execOperations.exec`

yea.  if it’s absolutely necessary to do that (suggest avoiding it at all costs), you could synchronize on something to prevent overlaps.  Perhaps a BuildService can help with that.

why are you exec'ing gradle instead of using <https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/GradleBuild.html|GradleBuild>?

<@U019L3NM4PK> <https://gradle-community.slack.com/archives/CAHSN3LDN/p1667339458239099?thread_ts=1667339458.239099&amp;cid=CAHSN3LDN|https://gradle-community.slack.com/archives/CAHSN3LDN/p1667339458239099?thread_ts=1667339458.239099&amp;cid=CAHSN3LDN>

```tasks.register&lt;GradleBuild&gt;("publishChild") {
    setDir("child")
    setTasks(listOf(":assembleArtifact"))
    startParameter.setProjectProperties(mapOf("publish.version" to version))
}```
or a composite build would usually be a better solution. even with a single daemon, they can have different AGP versions etc. (although obviously the same Gradle version)

With a single daemon, there can still need compile errors with incompatible AGP versions

I don't own the downstream app, this is why I need completely separate builds

With a single gradle daemon using the `GradleBuild` approach - wouldn't that transitively upgrade AGP versions? Or would it stay separate?

`GradleBuild` is a bad idea, especially if you don't know the downstream builds, because it does not support composite builds. As I said in the other thread, use the tooling API instead. Same effect, less problems, just a bit less convenient usage. In both approaches AGP should not be touched as the tasks run isolated. I'm right now not sure about Gradle version with `GradleBuild` as I didn't use it for long time, but using the tooling API you can use different Gradle versions.

For running the tasks sequentially, use a shared build service. That is *not* a hacky solution, but a clean one. Define a build service with max parallel usage of 1 and make the tasks use it. One of the use-cases for shared build services is to represent a common restricted resource, in this case CPU / Memory for example.

The idiomatic approach would be to use the maven coordinates (not the URL, which the repository/resolution would build up internally).  What is the subsequent task doing?

Writing out the url to some of the artifacts to a file so another tool knows where to download it from. Not exactly the most idiomatic usage of Maven

seems sketchy.  The other tool would need to be Maven-aware to get all the right stuff (incl. transitive dependencies, etc).  Not aware how to get a URL for a published artifact.  You could have a Gradle configuration that resolved the artifact from Maven and tasks(s) that then copy it (or otherwise process it).

It is pretty sketchy. We're basically abusing our maven repo as an S3 bucket (for unfortunate organizational reasons) and piggybacking off of the maven publish configuration we already have in our setup (so nothing transitive or anything like that). Just uploading and downloading a single file

Painful.  You don’t necessarily need the published  url - build it up using the same convention (group, name, version, etc).

Looks like that's my best bet forward. Thanks!

A few hints <https://stackoverflow.com/questions/29356796/intellij-gradle-plugin-the-supplied-javahome-seems-to-be-invalid|here>.  Check that you’re config points to the java home (not the binary) and that it’s the correct arch (32 or likely 64-bit).

Thanks. Yup. Tried just the folder, too.

I don't have a gradle app, per se, to check that environment setting... just Godot.

perhaps revert to the JDK that was working previously?  Unfamiliar with godot and how to further diagnose, sorry.

no worries. Thanks for the quick response!

For reference for anyone who needs it.
Apparently it needs the Android Studio JRE, not others like OpenJDK or Oracle. ¯\_(ツ)_/¯

`path-to\Android Studio\jre`

Hmm, afaik that's not really necessary. I use OpenJDK and Zulu JDKs for Android builds.

It's the only thing that worked. I had OpenJDK and Oracle's. Neither worked.

Hmm ,okay.  Intellij/Android Studio has an option to set the  the JVM per project , you could try toggling the Java version from there to see if still errors out.

&gt; Thanks. Yup. Tried just the folder, too.
&gt; 
Which? If your tried the `bin` folder, it's still not correct. It needs to be the parent of the `bin` folder.