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

Gradle Community

At <https://www.linen.dev/s/gradle-community|https://www.linen.dev/s/gradle-community> you can search also for older messages.

It is still the case.
&gt; The command `gradle test` will execute the `test` task in any subprojects, relative to the current working directory, that have that task. If you run the command from the root project directory, you’ll run `test` in _api_, _shared_, _services:shared_ and _services:webservice_. If you run the command from the _services_ project directory, you’ll only execute the task in _services:shared_ and _services:webservice_.
<https://docs.gradle.org/current/userguide/intro_multi_project_builds.html>

I was checking against a task publishing to  `build/repo` , it turns out I was looking only in the root, while every module has obviously its own `build`

It's not the full truth though.

If you run explicitly the root projects task using its full path `:build`, then only the root projects `build` task is executed unless you configured task dependencies manually.

If you run a task without any path (i.e. without it containing a `:` separator), then the magic kicks in that runs the task in all projects that have a task with that name.

If you for example trigger the root projects `build` task through the IDE tool window, it is equivalent to executing `:build`, not `build`.

no wait, I'm actually triggering a task through the IDE tool window, and it's calling in turn the tasks on the modules..

&gt; If you for example trigger the root projects `build` task through the IDE tool window, it is equivalent to executing `:build`, not `build`.
This isn’t what is observed.  A run configuration is created with `build` as the target, and all build targets in root and subprojects are executed.  At least that is the case in IntelliJ.

Oh, ok, then I had that detail wrong in mind, sorry.
I usually use Ctrl-Ctrl to run Gradle tasks, not the tool window.

it's ok, Vampire, only we peasant use the GUI :grimacing:

I don’t need to support multiple configuration points:

```config {
  // configure my convention plugin
}

// it's fine if this throws - and my convention plugin logic runs immediately after the `config` lambda above ends```

use a function to configure the extension, hooking the logic for post-configuration into the method (after configuration)

pseudo-code:
```fun Project.config(block : (MyExtension).() -&gt; Unit ) {
    val ext = &lt;lookup extension&gt;
    ext.apply(block)
    // do magic here
}```

so that’s _kind_ of what I’m doing - but I want to have this behavior:

```plugins {
  id("me.conventions.library.android")
}
config { // emits `MyAndroidLibraryConventionExtension`
}```
```plugins {
  id("me.conventions.app.android")
}
config { // emits `MyAndroidAppConventionExtension`
}```
where the same wording of `config { }` lambda emits a different value based on the convention plugin applied

I want to avoid the following (different function names):

```plugins {
  id("me.conventions.library.android")
}
configLibrary { // emits `MyAndroidLibraryConventionExtension`
}```
```plugins {
  id("me.conventions.app.android")
}
configApp { // emits `MyAndroidAppConventionExtension`
}```

I think you can't if you don't want to have it in the same package (root)

your approach is similar to slack plugin one, but without merging the plugins and keeping convention plugins

where is that approach described? Think I remember some article being posted about it

```plugins {
  id("me.convention")
}

config {
    android {
        library { ... }
        // app { ... }
    }
}```

with the config, android, library... extensions you collect the state, you emit an error if there is an inconsistent state, if the state is valid, you apply the plugins, in that case you apply android library plugin and the android block provides a custom dsl for android

```plugins {
  id("me.convention")
}

config {
    android {
        features {
            dagger()
        }
        
        library()
    }
}```


so I don’t like that particularly because it groups _everything_ under 1 plugin and makes the following throw (no default):

```plugins {
  id("me.convention")
}

config {
}```

I wonder if we can control what accessors gradle generates when a plugin is applied, like how it generates an accessor automatically for any extension defined

those accessors are named after the extension name.  e.g. `project.extensions.create&lt;Something&gt;("foo")` creates `foo` accessor.

```plugins {
  id("me.convention")
}

config {
}

// the problem is that I need a hook to run here, immediately before `afterEvaluate { }` - which gradle does not seem to provide```


yep. as above:
```fun Project.config(block : (MyExtension).() -&gt; Unit ) {
    val ext = &lt;lookup extension&gt;
    ext.apply(block)
    // do magic here
}```

don’t use the generated accessor, create your own.

see this <https://gradle-community.slack.com/archives/CAHSN3LDN/p1667417737953149?thread_ts=1667417506.722479&amp;cid=CAHSN3LDN>

I want to emit different values in the lambda depending on the convention plugin applied - like AGP

i.e. just `config { }` - not `configLibrary { }` / `configApp { }`

elsewhere I’m letting other plugins add to `config`, such that the DSL inside config is extensible.

```config {
    library {
    
    }
}```

…leaving the root extension to handle aggregating the configuration and doing the post-configuration notification.

```config {
    library {
    
    }
}```
I’d want `library` to fail compilation (as opposed to a runtime error) if we are working within the `<http://convention.app|convention.app>` plugin

I’m normally fine with workarounds, but this would be a public API that affects hundreds of subprojects

like this?
```plugins {
    id("my.rust.plugin")
}

cloudshift {
    golang {

    }
    rust {

    }
}```
…this would fail to compile as `my.golang.plugin` hasn’t been applied (which would register the golang extension).

how do you register an extension on an extension?

extensions are ExtensionAware.  So ext.extenstions.create.

```extensionAware.extensions.create&lt;GoLangExtension&gt;("golang")```


that would still allow this to compile though, right:

```plugins {
    id("my.rust.plugin")
}

golang {

}
rust {

}
cloudshift {
    
}```
which isn’t ideal

no.  those extensions are only registered in `cloudshift`.

if you follow the slack way, you can save the complete state of what the user want to build, so if the user applies a wrong configuration, for example `library` + `app`, you can know that state and emit an error in compile time with a custom message indicating that `library` with `app` can't work

you are not forced to nest it, you can do

```library { }

app { }```

Does that mean you can do the following then:

```cloudshift.goLang {
}```


and recollect that state to indicate an error

&gt; Does that mean you can do the following then:
&gt; ```cloudshift.goLang {
&gt; }```
…only if you also register an extension val on cloudshift for golang.

&gt; you can know that state and emit an error in compile time with a custom message indicating that `library` with `app` can’t work
Well it would mean compilation has to run and fail first. both are still on the compile classpath, and I would want to use generated extensions to avoid them

```public val CloudShiftExtension.golang: GoLangExtension
    get() = extensions.getByType()```

…allows `cloudshift.golang` to work.    separate from
```public fun CloudShiftExtension.golang(action: GoLangExtension.() -&gt; Unit): Unit```

One important question also is, whether you only want to support Kotlin DSL properly, or also Groovy DSL.
Because in the latter case the option to make an own extension function is not really feasible.

&lt;whew&gt;.  Yes, all that only works in Kotlin.

What about if both plugins are applied, is that invalid or could that legally be?

we have 3 convention plugins currently (android library, android app, java library) - only 1 of them will be applied at any time

What you could do, but you might not like it, is to have one method in your extension and then have
```config {
    whatever {
        // actual configuration here
    }
}```
and then you can do your post-configure actions in the `whatever` function after executing the given action block and throw if the method is called a second time.

Our current approach, with a `data class` which is nasty
```// setting `moduleConfig` executes our convention plugin configuration logic immediately
// and can only happen once per project
moduleConfig = me.Module(
    gradlePath = project.path,  // silly 
    convention = LIBRARY_JAVA, // silly - should know automatically the library convention based on the applied plugin
    isPublished = true, // silly, bc our app can't be published
)```
I want to change it to:

```config {
  isPublished = true // field would not exist in an Android app project
}```


yeah I guess I have to do some workaround here :confused:

I think my best approach would be something like:

```moduleConfig = config {
 
}```
and evaluate immediately once `moduleConfig` is set

Another fancy option:
```interface AppConfigValues {
    val setting: Property&lt;String&gt;
}
abstract class AppConfig {
    @get:Inject
    abstract val objects: ObjectFactory

    infix fun ig(action: Action&lt;AppConfigValues&gt;) {
        val setting = objects.newInstance&lt;AppConfigValues&gt;().also(action::execute).setting.get()
        println("configured $setting")
    }
}
project.extensions.create&lt;AppConfig&gt;("conf")```
and then
```conf ig {
    setting.set("YAY!")
}```

Or
```interface AppConfigValues {
    val setting: Property&lt;String&gt;
}
abstract class AppConfig {
    @get:Inject
    abstract val objects: ObjectFactory

    operator fun rem(action: Action&lt;AppConfigValues&gt;) {
        val setting = objects.newInstance&lt;AppConfigValues&gt;().also(action::execute).setting.get()
        println("configured $setting")
    }
}
project.extensions.create&lt;AppConfig&gt;("config")```
and then
```config % {
    setting.set("YAY!")
}```


Or any of the other overloadable binary operators: <https://kotlinlang.org/docs/operator-overloading.html#binary-operations>

```config .. {
    setting.set("YAY!")
}```
or any other, just pick one

Just not `invoke` as the type-safe accessor with action argument will win then

Well, the one argument `invoke` that is.
Two argument `invoke` would work too:
```interface AppConfigValues {
    val setting: Property&lt;String&gt;
}
abstract class AppConfig {
    @get:Inject
    abstract val objects: ObjectFactory

    operator fun invoke(nothing: Nothing?, action: Action&lt;AppConfigValues&gt;) {
        val setting = objects.newInstance&lt;AppConfigValues&gt;().also(action::execute).setting.get()
        println("configured $setting")
    }
}
project.extensions.create&lt;AppConfig&gt;("config")```
and then
```config(null) {
    setting.set("YAY!")
}```

side note, kind of a bummer that `Property&lt;String&gt;` has to have:

```setting.set("YAY!")```
instead of:
```setting = "YAY!"```
bc the latter is so much nicer. I wish kotlin could support _both_ options somehow

Kotlin native support for assignment operator overloading is more or less rejected. But the Gradle guys are working on a compiler plugin to make the syntax possible.

This magic snippet let’s you do `setting.finalValue = “YAY!”
```public var &lt;T&gt; Property&lt;T&gt;.finalValue: T
    get() = throw UnsupportedOperationException("Do not use property.value; call property.get() if that is what is intended, or use .from(property) to chain properties together")
    set(value) = value(value).finalizeValue()```

Or this one if you don’t want to also finalize the value:
```public var &lt;T&gt; Property&lt;T&gt;.value: T
    get() = throw UnsupportedOperationException("Do not use property.value; call property.get() if that is what is intended, or use .from(property) to chain properties together")
    set(value) {
        value(value)
    }```

added a gradle issue on this <https://github.com/gradle/gradle/issues/22606>

<@U02S31Y7J2K> what’s the benefit of finalizing the value?

Don't use JCenter, especially for getting AGP which is hosted on Google's own repo?

```Thank you, but I already know the reason for the problem, it is that I am from Cuba and the server gave me the sanctions, thank you very much.```


&gt; it is that I am from Cuba and the server gave me the sanctions
No, in this case it is because JCenter (<http://jcenter.bintray.com|jcenter.bintray.com>) has been decommissioned a while ago and your build still relies on it.

See <https://developer.android.com/studio/build/jcenter-migration>.

<https://onesignal.com/blog/android-migrate-jcenter-to-maven-central/>

No <@U01QHF1A6HJ>, JCenter has not been decommissioned.
It stays forever as read-only instance (besides the regular outage it suffers from)

Then maybe there's an outage right now? :upside_down_face:
```# curl -i <https://jcenter.bintray.com/com/android/tools/build/gradle/4.0.0/gradle-4.0.0.pom>
HTTP/2 404 
via: 1.1 google
date: Fri, 04 Nov 2022 04:27:47 GMT
content-type: application/json;charset=ISO-8859-1
content-length: 88
age: 20946
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

{
  "errors" : [ {
    "status" : 404,
    "message" : "Could not find resource"
  } ]
}```
Either way, migrating the build away from JCenter seems a good call…

&gt;  Then maybe there's an outage right now?
No, not another one.
What you get is a 404, because it is neither on JCenter nor MavenCentral where it would forward to.
In that case Gradle would look in the next defined repository which probably is `google()` in that build and that would have the requested dependency.

OP though gets 403 which is probably caused by him being in Cuba and in that case Gradle does not look further as it sees that as misconfiguration of user credentials for example.

&gt; Either way, migrating the build away from JCenter seems a good call…
Definitely, but from what I see, I'd guess he didn't author that build but just want to run it.
In some cases some tools that wrap Gradle calls also have some auto-generated Gradle project templates they use that use JCenter and where you cannot easily remove its usage and so on.

The `sonarqube` task and extension has been renamed to `sonar`. Try `sonar.skipProject=true`.

• <https://github.com/SonarSource/sonar-scanner-gradle/pull/126>
• <https://sonarsource.atlassian.net/browse/SONARGRADL-93>

Gotcha, didn’t expect breaking changes in a minor. The release notes didn’t mention this at all:
`Update cirrus yml to use gradle wrapper`
<https://github.com/SonarSource/sonar-scanner-gradle/releases/tag/3.5>

I’ll update accordingly and test it out then. Thanks!

Interesting. I wonder why they rename it back now when they renamed all from "sonar" to "sonarqube" in the past due to a name conflict with something else called "sonar".

My guess is corporate amnesia…
They could've used `sonarScanner` instead. :shrug:

I think they only renamed it from `sonarRunner` to `sonarqube` in the past.
<https://github.com/SonarSource/sonar-scanner-gradle/commit/4acdce0a268c3403e724982fc97434b423761aed>

Probably not really appropriate. :smile:
But anyway, at work we use Nexus Repository Manager for Maven repositories and other things.

Oh English weirdness. I meant a hosted repo for private artifacts.

Disable the ones you don’t want, or enable just the ones you do (whichever is easiest).  Something like
```

tasks.withType&lt;PublishToMavenRepository&gt;().configureEach {
	onlyIf { // condition here }
}```

Is there a way to log the reason why it's being skipped?

only in comments; nothing in API.  There’s a rejected enhancement <https://github.com/gradle/gradle/issues/3024|request>.

That's unfortunate. Was it actually rejected, or just closed because it was stale?

it shows as being closed as “not planned”

I think <@UA8P8BBEG> had something that automatically did that to issues that were marked as stale.

Actually, the issue has been fixed in 7.6.

<https://github.com/gradle/gradle/pull/19428|https://github.com/gradle/gradle/pull/19428>

But actually for unconditional disabling or disabling that is determinable at configuration time, I'd probably use `enabled = false`, not `onlyIf { ... }` as then nothing has to be evaluated.

It had two days ago.
Not aware of another outage.
What error do you get?

Plugins that were resolving a few hours ago now say that they can't be found in any of the sources (including the plugin portal). If I check <http://plugins.gradle.org|plugins.gradle.org> they are there.

There were no gradle or environment changes. One build worked fine, next one failed

Well, can only guess.
If it really were the plugin portal, there are usually more headless hens running around here and in the forums. :slightly_smiling_face:

Could be my remote build cache. I'll try clearing that

I actually doubt it, does not sound related to build cache.
But who knows. :slightly_smiling_face:

Always worth a try in my book because it's helped in weird situations. Alas it did not help here.

If this is Flutter-specific problem, you might want to move to <#C03EM93810S|>

I didn't see that channel thanks. I feel this is a general Gradle problem, because things only started getting weird when I added multiple buildTypes and productFlavors.

Then maybe <#CJYS1DAP5|>?
build types and product flavors are not general Gradle. :slightly_smiling_face:

Besides that you do not "implement" something, but add a dependency to the "implementation" configuration, what you ttied works perfectly fine here:

Yeah excuse my wording, by “implementing” there I meant more like “use the `implementation` API” :sweat_smile:

But yeah this does not show up for me at all, I wonder which API is it that your IDE is finding?

For me none apply as seen in the attached image.

Since the `fun implementation(dependencyNotation: String, configure: ExternalModuleDependency.() -&gt; Unit): ExternalModuleDependency` one doesn’t work since libs… isn’t a string, and the `fun &lt;T : Dependency&gt; implementation(dependency: T, configure: T.() -&gt; Unit): T` doesn’t work either since libs… is not a `Dependency`, but it returns a `Provider&lt;MinimalExternalModuleDependency&gt;`, so none of the available functions match.

Is it that there’s some API that I don’t see, or that `libs.kotlin.lib` returns a different type for you somehow?

D:\Dateien\.gradle\caches\7.5.1\kotlin-dsl\accessors\9825c21096ee88b996b20a7c4aa46764\sources\org\gradle\kotlin\dsl\ImplementationConfigurationAccessors.kt

Awesome thanks for sharing this!
I seem to also find this in deep in my `.gradle` directory, just does not resolve for this file.
Doesn’t seem to work to manually import it either hmm.
Not sure if it matters that for that build.gradle.kts file I am using `kotlin("multiplatform")` instead of jvm and maybe it’s instead named something else there.

Yeah, nevermind this, it’s not a big deal anyway. Gonna leave a normal // comment instead of now :man-shrugging:

With KMP you use a speparate `dependencies` block that has nothing to do with the Gradle `dependencies` block.
It is purley provided by the Kotlin Gradle plugin, so you need to complain to JetBrains.

Yes, I might just go ahead and do that :sweat_smile:
Thanks a lot for your help!

kmp doesn’t generate accessors, it uses the interface that <@URQ797WRW> has mentioned.

maybe you can try `“implementation”(…) { }`

Version catalogs support the concept of a bundle of dependencies.

As an example: <https://dev.azure.com/TerracottaCI/ehcache/_build/results?buildId=9975&amp;view=logs&amp;j=699eab8d-7341-5b94-873e-ae483acce31c&amp;t=bd32b9f3-1cb1-588e-44b9-5a0f46e80d0e|https://dev.azure.com/TerracottaCI/ehcache/_build/results?buildId=9975&amp;view=logs&amp;j=[…]-5b94-873e-ae483acce31c&amp;t=bd32b9f3-1cb1-588e-44b9-5a0f46e80d0e>

Try adding Maven Central before the plugin portal in your settings `pluginManagement`

whoops… you mean this is a bad idea:
```repositories {
  gradlePluginPortal()
  mavenCentral()
}```

Yes, swap it around. 
And if you want to optimize it, exclude specific plugin markers and artifacts from maven central resolution 

you could also not wipe out caches, there are a set of directories that are documented safe to be copied. <https://docs.gradle.org/current/userguide/dependency_management.html#sub:cache_copy>

yeah… just realized this is uglier than I expected - that existing reference (in the `build-logic` project) is there because I have explicit non-plugin dependencies. What’s the timeline on an infrastructure fix for this before I commit to also adding an entirely new repositories section to the top level `settings.gradle`?

and this is breaking some of our internal builds too because they depend on an artifact that has a version range in it’s dependency set… so it wants to resolve the version range available in jcenter :shrug:

you can use `content.(include|exclude)(Group|Module|Version)(ByRegex)?` in your repository definition to limit which artifacts Gradle will attempt to look up there

3. a new task that extracts the specific line from the file and puts it in a temporary file, then configure your original task to use that temporary file as input

by the way, it is possible for your task to handle this internally: <https://docs.gradle.org/current/userguide/custom_tasks.html#sec:storing_incremental_task_state>
but unless you have specific needs otherwise, I think using a pre-processing task is easier

Any update on the plug-in portal? The status page says sporadic issues, but it’s been a while since an update, and it’s still blocking. One of our plugins has a dependency that isn’t in maven central. 

Probably by defining an exclude on the classpath configuration in the build script block.

<@URQ797WRW> thank you! I need to remove a dependency of a particular *version*. Because the plugin is brings a older version of the library that is being flagged by the white source. Is it possible?

You should be able to do all usual things you can do for other configurations too, including upgrading that version, or rejecting that specific version, or excluding, and so on. Just have a look at the user guide what is possible.

I don’t seem to be finding much in case of plugins after a whole day of googling :smiling_face_with_tear:. If you could point to the link that would be great.

I tried this with no luck

```implementation("com.google.code.gson:gson") {
			version {
				strictly("2.9.0")
			}
	}```

It still gets the gson2.8.6 dependency too

This did not work either

`implementation('com.google.code.gson:gson:2.9.0') {`
  	`force = true`
  `}`

All these technique don’t seem to be helping much when it comes dependencies got by plugins

As I said, you have to do it for the `classpath` configuration in the `buildscript` block, not for the production dependencies in the `implementation` configuration.

```buildscript {
    dependencies {
        classpath('com.google...') { ... }
    }
}```

Can the `force=true` and `strictly`  be used in the buildscript block.

I think so.
While `force` should usually not be used anymore nowadays

<@URQ797WRW> this seems to have done the trick :raised_hands:

```buildscript {
    dependencies {
        classpath('com.google.code.gson:gson') 
				{ 
					version {
						strictly("2.9.0")
					}
				}
    }
}```

Btw. `classpath('com.google.code.gson:gson:2.9.0!!')` should also work if you want it more compact. `!!` is the inline notation for strictly

Gotcha! Thank you very much for all your help. I was pulling out my hair the whole day y’day!

<http://quoy.io|quoy.io> is an empty domain.
But other than that, isn't it up to you where you pull Docker images from?

Yes, but just wanted to confirm if nothing is set then the images are pulled from dockerhub?

Hey, <@U04A01ZFUSX>! If I understand your question correctly, this doesn't really have anything to do with Gradle specifically and is more of a Docker question. That being said, I may be wrong but by default Docker will pull from <http://docker.io|docker.io>.

This should be true regardless of the base image you use.

Also, found this as well: <https://github.com/cloud-native-toolkit/planning/issues/679>

Not really, besides that the settings script looks cleaner. If you do `include(":features:feature1")` it automatically creates both projects, `features` and `feature1`. If you want direct child but in subdir, you have to do `include(":feature1"); project(":feature1").projectDir = ...)`. But other than that, it is totally up to you how you structure your project tree.

first goal would be to shrink the reproducer scope to remove the need for those dependencies.  If that’s not possible, grab the necessary dependencies and do something like this in the reproducer.
```dependencies {
    implementation(files("libs/something_local.jar"))
}```

<@UF050PN14> This should work:
```repositories {
    maven("file:///path/to/local/repo")
}```

Thanks. I know I can have a local file repo. I was looking for a way to automatically resolve all of the private dependencies then create a repo out of the resolved files such that i don't have to manually download each one individually (it's about 20 dependencies) and so that i don't have to go into all our modules (about 20 modules also) and change every dependency declaration from the gav to the local file :(

With what Thomas said, you can keep the GAV. But there is no convenient way to replicate the file structure I think.

Yep, `buildSrc` result is automatically prepended to all build script class paths, which also is one of its biggest drawbacks. (invalidating everything if something changes).

You have to bring your included build to the build script classpath where you want to use the class.
You can either do that explicitly using `buildscript { dependencies { classpath(...) } }`, or you can have some dummy plugin that does no actions and apply that dummy project to your build script, because that brings the classes onto the classpath.

thanks <@URQ797WRW>, that helped me to make it work.

I had to define a <https://docs.gradle.org/current/userguide/composite_builds.html#included_build_declaring_substitutions|dependencySubstitution> to be able to reference the included build from `buildscript`

Is this always needed or is there also a way to reference the artifact without the substitution?
i have also tried to set _group/name_ just in the included build but that does not seem to work.

```// settings.gradle
includeBuild('buildLogic/helper-function') {
    dependencySubstitution {
        substitute module("demo:helper-function") using(project(':'))
    }
}

// build.gradle
buildscript { dependencies { classpath("demo:helper-function") } }

task demo {
  doLast {
     // this is the imported helper function
     println demo.Helper.sayHelloTo("foo")
  }
}```

If your included build is properly set up, you do not need dependency substitutions.
Dependency substitutions are always only necessary if the included build is not configured properly, or if it does fancy non-standard things.

Why it does not work in your case is hardly guessable without an MCVE.

My searches aren't coming up with anything

you could filter out just what is needed, though it may be presumptuous that CI failures are solely due to compiler errors.

This job runs just compile java, its to find compile issues at the commit level

Ill send the output somewhere and write some regex to find it

If the included builds are via `include("some-other-module")` then only the root gradle.properties is used.

It's more like `includeBuild("some-other-project")`

ah yea.  unsure on how composite builds process gradle.properties.

for all our projects there’s a core convention plugin that, among other things, standardizes certain settings in gradle.properties.

Can this be even done in a plugin ? :thinking_face:

Like `jvmArgs`  needs to be read before the dameon starts

it can be done in a plugin, but changes only take effect on the next run.

Super curious how that works. Do you have any documentation on this?

nothing fancy.  simple custom task that takes a gradle.properties template as input, has gradle.properties as output, will only run if the template has changed.  really no different than manually editing it, but baked into the builds so things stay consistent at scale.

sorry to disappoint.  i’m often hoping to learn of some super-secret-awesome-api that saves the day :wink:

```@CacheableTask
internal abstract class WriteGradleProperties : DefaultTask() {
    @get:OutputFile
    abstract val gradlePropertiesFile: RegularFileProperty

    @get:Input
    abstract val defaultProperties: MapProperty&lt;String, String&gt;

    @TaskAction
    fun taskAction() {
// merge logic here
}
}```

As far as I know composite builds don't get gradle.properties passed along: <https://github.com/gradle/gradle/issues/2534>

The build cache configuration is for the whole build and will be passed down to included builds. Whether the build cache is on or off is also a build wide setting and can’t be changed on a per included build level.

Here is some documentation on that behaviour: <https://docs.gradle.org/current/userguide/build_cache.html#sec:build_cache_composite>

Thanks! Looks like "it depends" then? For a given Gradle property, can I know if it's going to be passed down or not, besides trying it?

I am pretty sure all the Gradle properties will be used from the root build and affect all included builds as well: <https://docs.gradle.org/release-candidate/userguide/build_environment.html#sec:gradle_configuration_properties>

had a very similar issue.  iirc, tried with `--refresh-dependencies` first and think I ended up removing ~/.gradle/caches.

also - for 7.6.x, it s/b Kotlin 1.7,10; that error message is referencing 1.7.21, perhaps something is bumping the Kotlin version.

I bumped to 1.7.21 (which was released today I think)

The embedded Kotlin with Gradle is 1.7.10, best to stick with that for Gradle components (such as the referenced plugin-api).

yep, the root of both goodness… and challenges…

Removing ~/.gradle/caches, see you in a bit !

ok.  Presuming this is a Gradle plugin.  Ensure this is correct:
```plugins {
    `kotlin-dsl`
    // DO NOT use kotlin("jvm") here as this is a Gradle plugin that will use the embedded Kotlin, pulled in by `kotlin-dsl'
    // also: it's redundant to use `java-gradle-plugin` (already pulled in by `kotlin-dsl`
}```

I'm using
```plugins {
  `embedded-kotlin`
  id("java-gradle-plugin")
}```

I'm avoiding `fun String.invoke()` in my classpath :sweat_smile:

ouch.  that’s likely part of the problem.  partial setup, `kotlin-dsl` does what you need.

I'll remove the "java-gradle-plugin" part, see if that changes anything

it won’t work w/o it - that’s what pulls in the Gradle API.  You want `kotlin-dsl` to write Gradle stuff.

not following why `kotlin-dsl` isn’t being used to pull in the standard set of things?

you can, of course, reproduce that yourself, including keeping up with changes between Gradle versions.

Turns out it's the "java-gradle-plugin" that seem to mess with resolution :thinking_face:

perhaps flip the order?  In `kotlin-dsl` they’re done in a different order:
```        apply&lt;JavaGradlePluginPlugin&gt;()
        apply&lt;KotlinDslBasePlugin&gt;()
        apply&lt;PrecompiledScriptPlugins&gt;()```
…the middle one is embedded kotlin.

This is working on 7.6-rc-2:
```plugins {
    `embedded-kotlin`
    `java-gradle-plugin`
}

repositories {
    mavenCentral()
}```

having said that, it’s minimal - no code, etc.

The `kotlin-gradle-plugin:1.7.21` is the one that fails to resolve

yea, guessing that is pulled in by the embedded kotlin.  How was the 1.7.21 version specified?  only seeing 1.7.10 resolved.

Mmmm this is working as well... I'll dig
```plugins {
  id("java-gradle-plugin")
  `embedded-kotlin`
}

repositories {
  mavenCentral()
}

dependencies {
  implementation("org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.21")
}```


even with the above it still pulls in kotlin-gradle-plugin (and other stuff) at 1.7.10.  Visible via `./gradlew --refresh-dependencies --info | grep https`.  Something else must be forcing 1.7.21.

something in settings.gradle.kts `buildscript` perhaps.

Alright, it all boils down to this:
```plugins {
  id("java-gradle-plugin")
  `embedded-kotlin`
}

repositories {
  mavenCentral()
}

dependencies {
  implementation("org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.21")
  implementation("org.jetbrains.kotlin:kotlin-allopen:1.7.10")
}```

that appears to work … wait … it fails when doing `./gradlew test`.

Aaahh `Error while evaluating property 'paths' of task ':pluginUnderTestMetadata'.`

yea.  wondering if forcing version alignment will fix this, trying that…

That explains why it's caused by the "java-gradle-plugin"