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

Gradle Community

I expect it will be easier to write a simple regular test which exec's whatever program you want to run

build.gradle.kts.kt

I was curious enough to dig into it and… _possible_, but it's very not public, and definitely not better than writing a regular test

Interesting, thanks <@U019L3NM4PK>. :slightly_smiling_face:

Also: <https://xkcd.com/356/> :wink:

Hi <@UM9DAFSF4> - build scans can tell you this …

The above is from `performance/configuration` …

That’s the inspector, accessible via this blue icon:

`Created immediately` means that the task was not created lazily.

`Created during configuration` these are the tasks that were realized during this script/plugin (i.e. what you are looking for). It’s not where they are registered, but where they are created/realized.

I'm aware that normally the build scan shows you this information, but the issue is that no script/plugin shows that it created/realized any task yet I'm seeing that tasks are created during configuration.

In the second red block, there is no "x tasks created".

Add a configuration action to all tasks and set a breakpoint within?

(Tried it with the Gradle Enterprise plugin 3.10 and Gradle Enterprise 2022.2)

Thanks again <@URQ797WRW>, that of course works, didn't think of it
```allprojects {
    tasks.configureEach {
        println "${it.project.path}:${it.name} configured"
    }
}```

<@UM9DAFSF4> when you say second block, you mean the one with (2) right? I see `94 tasks created` and `519 tasks created`  there. I’m not quite sure what you are referring to with “no script/plugin shows that it created/realized any task”.

That screenshot is from the docs, this is what I'm seeing (cannot really share more :/)

Not sure what’s going on here then. If you’re able, please share the nature of where these things are being resolved as it may be case we don’t handle.

<@UEL10RAQZ> I found an issue which seems to be exactly what I was running into, <https://github.com/gradle/gradle/issues/19498|https://github.com/gradle/gradle/issues/19498>. Not sure if this can or should be caught in the build scan.

You could simply add a second test task with the same configuration except for the property

Yes, that's what I wanted to express with the last sentence. :sweat_smile:

Is there a simple way to "clone" an existing `Test` task?

not really. but I think by default a new test task takes at least the same classpath and testClassesDir configuration than the `test` task.

you can simply configure the common settings via `tasks.withType(Test).configureEach`

Okay, I just realised, that it does work for most projects, except for those using the `java-test-fixtures` plugin.

And the projects with the `java-test-fixtures` plugin don't even contain integration tests, which means the problem probably has nothing to do with `test` vs. `integrationTest` but only with usage of `java-test-fixtures` . Is `sourceSets.test.runtimeClasspath` not the same when using this plugin as it is without?

I suppose you can use it as an output with `@OutputFiles`.

I thought that `@OutputFiles` only works with `List&lt;File&gt;` and not with that type

It works with maps as well: <https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/OutputFiles.html>

I expect to use `Map&lt;String, List&lt;File&gt;&gt;`, not `Map&lt;String, File&gt;`

So I am getting `Expected file collection to contain exactly one file, however, it contains more than one file`

I did this as a workaround

```    @Internal
    val commonMainDrawablesGroupedBySuffix: Map&lt;String, List&lt;File&gt;&gt; =
        commonMainDrawablesGroupedBySuffix(commonMainResourcesDirs.toList(), suffixes.get())

    @OutputFiles
    val commonMainDrawables: List&lt;File&gt; = commonMainDrawablesGroupedBySuffix.values.flatten()```

it works, but the problem is `commonMainDrawables` is marked by the IDE as not used, which is technically true

You can use `@Nested` for outputs, though you’d need to define your own type. Something like should work:
```class MyOutput {
    @OutputFiles
    List&lt;File&gt; outputs
}

@Nested
val drawables: Map&lt;String, MyOutput&gt;```


I had a different issue, sorry, with the new implementation even I don't need that output anymore, thank you for your help and I note the trick for the next one! :)

Hate to tag anyone, but I so desperately need a solution for this <@U023HSZL88M>

I don’t think I can help here. Never had such problems.

I would suspect some port connection issue deep down in you system. When you start a build, there are at least two JVM processes involved (client and daemon) and maybe they have some problem communicating.

Maybe if you search the gradle issues and forum for such problems you can find hints.

Regarding 2: I think the approach (or variations of it) are fine. There should be no unwanted side effects. I do things like this often.

Regarding 1: This was once discussed at Gradle (<https://github.com/gradle/gradle/issues/14566>) but IIRC it was hard to come up with a general good approach fitting everyone (do you look in *all* folders down the hierarchy like you are doing? Or only the direct children? etc.) My feeling is that this is very individual so it is probably fine if Gradle does not offer much more out of the box.

If you do not want to have this code “polluting” the central settings file, you can consider defining a _Settings Plugin_ for that in a (small) included build (<https://www.youtube.com/watch?v=tlx3tzuLSWk&amp;list=PLWQK2ZdV4Yl2k2OmC_gsjDpdIBTN0qqkE>)

Personally, I'd avoid this because it's complex code that solves something that I consider a non-problem, and if it breaks, it probably breaks in ugly ways. But that might just be defensive old me.

I agree that this particular solutions looks a bit complex. :slightly_smiling_face: Ideally the projects are not in arbitrary subfolders but only e.g. on one hierarchy level. Then the code can be much simpler. E.g.:
```rootDir.listFiles()?.filter { File(it, "build.gradle.kts").exists() }?.forEach { subproject -&gt;
    include(subproject.name)
}```

Thanks for all the insights! That’s exactly what I was hoping to hear!

In our case, we wanted to be able to have subprojects in nested subdirectories to “group” related subprojects together in a hierarchical way.
I agree this may sound complex, perhaps in the future we might reevaluate this decision.

There are also other aspects why this is hard to do right generically. Build scripts don't have to be called `build.gradle.kts` but can also be called `foo.gradle.kts`, projects don't need to have an actual build script, even if there is a build script, it might just be some example project, even if it has a build script it might be a sub-build of a composite build instead of a sub-project, ...

I implemented this exact solution at our organization as the settings.gradle file was a common source of merge conflicts in massive mono repos. I did it the way that Jendrik suggested and wrote a Settings plugin to do this and recursively search the directory structure for any build.gradle or build.gradle.kts files and call Settings.include() on that folder path in the proper format. 

But the implementation had to take into account things that Jendrik and Vampire both mentioned. Some of our repos were creating Gradle plugins and we have build.gradle files in the src/test/resources folder that we use in our GradleRunner tests, so we had to ensure certain folders are excluded. I feel like the solution is absolutely going to be somewhat custom from org to org and there's no good way for Gradle to do this themselves. The Plugin/Settings API that Gradle currently publishes is the best way to allow organizations to do this simply in a way that fits their needs.

worth checking how IntelliJ is configured to run Gradle (which JVM is it using), and whether this is an M1 or Intel Mac (the screenshot indicates Intel, is it possible this was migrated to M1 at some point).

I am finding it impossible to get gradle to work

there are some reports that this error is due to invalid permissions for ~/.gradle; perhaps try `chmod 777 ~/.gradle`

Yes I had tried, but it doesn't create the .gradle folder in the .-directory.
Why does this happen?

what is `GRADLE_HOME`and `GRADLE_USER_HOME`set to?

I don't have those environment variables, I just looked for them with the command `printenv`

Does the error happen when running `./gradlew`from the command line?

In your project directory?  If your project is using gradle it will have a gradle directory and `gradle.bat`and `gradlew`scripts.

what should be set to `GRADLE_HOME` and `GRADLE_USER_HOME`  ?

`gradlew`is there.  Run `./gradlew`in that directory (perhaps it needs `chmod +x gradlew`)

what is the output?  Is it the same error?

that the chmod.  `./gradlew` executes gradle.

yep.  permission problem.  does this run successfully? `mkdir ~/.gradle`

I added `sudo` and then the passwrod and there was no error...

ok.  you should not have to sudo to create a directory in your home directory.  what are the permissions on your home directory?  `ls -ld ~`

yea, its there now, but Gradle won’t be able to create folders underneath it as it was created by root.

although there is something janky about the user/group setup - those big numbers should be username/group, looking like:
```drwxr-xr-x+ 61 chrislee  staff  1952 11 May 12:16 /Users/chrislee```

may be a problem with the user and permissions?

check the permissions on the new ~/.gradle folder, if they are good (owned by your user and drwx permissions) try running ./gradlew again

what is the output from
```find ~/.gradle -depth 1```

these are the permissions of another person

yea, ~/.gradle is owned by root. check your current username with `echo $USER`and use that in the following command

Replace USER with your username
`sudo chown "USER" ~/.gradle`

run that in the project folder, as before.

good stuff.  the root cause is something to do with your MacOS user account / home directory permissions.

should be good to go now that we manually got the ~./gradle directory created.

I don't know how to thank you, thank you so much, thank you so much! If it wasn't for you, I would lose a few days on this !

But you should really fix up your home directory permissions. Many programs will want to write in there and fail due to strange permissions.

If this is true, I will see the administrators to fix it ! Thank you very much

<https://gradle-community.slack.com/archives/CA7UM03V3/p1651787006908099|https://gradle-community.slack.com/archives/CA7UM03V3/p1651787006908099>

what does any of this have to do with gradle?

As this is a _compile error_, there should be a failure printed further up by the compileDebugKotlin task. Please check that and post that error here if you can’t make sense of it.

Indeed! Some really good features to test out.
<https://github.com/gradle/gradle/commits/v7.5.0-M1>

Not really.
IntelliJ injects things via init script and then calls some methods via tooling api.

Nice!

Have you considered supporting an additional property in the version catalog toml for binding module name to GAV rather than `moduleNameToGA` in the gradle build file? And avoiding having a naming convention for the version so it can be reused across dependencies?

I'm imagining:
```[versions]
commonslang = "3.12.0"
jackson = "2.12.5"

[libraries]
commons-lang3 = { module = "org.apache.commons:commons-lang3", version.ref = "commonslang", jpms.name = "org.apache.commons.lang3" }
jackson-core = {  module = "com.fasterxml.jackson.core:jackson-core", version.ref = "jackson", jpms.name = "com.fasterxml.jackson.core" }
jackson-databind = {  module = "com.fasterxml.jackson.jackson-databind", version.ref = "jackson", jpms.name = "com.fasterxml.jackson.databind" }```
Don't know how easy it is to extend the TOML spec in this way, but it might be a way to keep the metadata together without relying on `modules.properties` / `unique_modules.properties`, and still remove version duplication.

I don’t think the Catalog is designed for such extensibility. The integration right now also does not feel really good to me.
I tried that, because we need a place for _Versions_ and the Catalog has a _[versions]_ section. That sound like a fit in theory. But there are issues. Like that you can’t refer to a version that you have already declared. And you can’t use the exact names either because `.` is not allowed.

Right now, I think the Catalog is not a good fit for Java Module projects as you don’t use much of its features anyway. Right now defining versions in constraints using the `gav("module.name", "version")` notation feels like the better solution to me.

For the mappings: I want the plugin to deliver them so that you don’t need to define them at all. Because they are (with minor exceptions) unique and universal. The idea is really that in the ideal case you never have to deal with coordinates anywhere in the build. And if, only for a few mapping adjustments you do deep down in your convention plugins (and rarely touch).

Why do you want to define mappings yourself?

I'm suspicious of things that depend on bundled metadata - it gets stale so easily if no-one's being paid to look after it for the long term. And I feel a bit odd about that uncertainty of "does the tool know about this lib? No, have to tell it..." - I quite like the simplicity of just telling it about every lib.

I'm also hopeful that the toml is sufficiently standardised and easy to parse that it will rapidly become something tools like dependabot can reliably work with.

Yes ok that’s a bit different perspective on it. You already can define your own mappings. Just not in the Catalog.
Whether that should be made more extensible is a topic on its own. I am pretty sure it is not possible right now.

But I am happy to talk about extending the DSL the plugin offers if there are good arguments. e.g.:
• Deactivating the bundled mappings completely (that sounds useful and shouldn’t be too hard)
• Offer an API to directly define a mapping with a version (which would be what you proposed above I think, just not in the catalog but in the normal DSL)
Feel free to open an issue for these.

Sorry Steve, didn't have time for the forums lately :smile:

You've given me more than enough help  to not have to apologize <@URQ797WRW> :smile:

<@UFDR8S97S> suggested this might be a better place to ask anyway

that’s an odd exception - as I read it, it’s due to:
```Caused by: java.lang.ClassNotFoundException: &lt;path&gt;.service.CommonQueueService```
…the package naming is obviously incorrect.  Any idea what CommonQueueService is?

perhaps due to this code trying to load that class:
```Caused by: java.lang.NoClassDefFoundError: &lt;path&gt;/CommonQueueService
        at uk.gov.di.ipvspot.integrationtests.Slice3FeatureSteps.&lt;init&gt;(Slice3FeatureSteps.java:30)```

on line 30 of the constructor for `<http://uk.gov|uk.gov>.di.ipvspot.integrationtests.Slice3FeatureSteps` it’s trying to load that as a Java class.

```        function3QueueService = new CommonQueueService(client);```

huh.  somewhere that class (which presumably is in a package structure) is getting resolved as `&lt;path&gt;.service.CommonQueueService`

Sorry I dont knwo what that means..I am new to java :disappointed:

no worries.  it isn’t anything in that code snippet - tbh, short of something that is transforming the compiled Java, it seems impossible to have this happen.  What is the full package name (or import statement) for `CommonQueueService` ?

```import software.amazon.awssdk.services.sqs.SqsClient;
import software.amazon.awssdk.services.sqs.model.*;```

yep, those are for the AWS SDK; where is `CommonQueueService` imported?

`import <http://uk.gov|uk.gov>.di.ipvspot.spotmodule.service.CommonQueueService;`

ok.  that package structure is being replaced with `&lt;path&gt;.service.CommonQueueService`.  Is there anything in the compilation steps for these tests that manipulates the source or transforms class files?  Something that would replace `<http://uk.gov|uk.gov>.di.ipvspot.spotmodule` with `&lt;path&gt;`

yes sorry I have already replaced ``<http://uk.gov|uk.gov>.di.ipvspot.spotmodule``  with &lt;path&gt;

ugh.  ok.  in that case, it’s not as cryptic an error as it may seem - that class is simply not found on the classpath.  You’ll need to track down where it lives and adjust the classpath accordingly.

ok I will check that. Thanks for your help Chris :slightly_smiling_face:

It would more be `@UntrackedTask` / `doNotTrackState()`. The task can never be up-to-date if you change the file in-place, because if either the input or output changed, the task is out-of-date.

If you do this to insert versions and similar things, I usually have a readme template that I transform to the actual readme in the release process. This way placeholders get replaced and at the same time, the readme on GitHub always shows the state for the last released version as in the meantime I only edit the template and have a check task that ensures the readme was not changed, for example by a PR that is not aware of the template.

Like this: <https://github.com/Vampire/command-framework/blob/master/buildSrc/src/main/kotlin/net/kautler/readme.gradle.kts>

This is clearly Android specific, ask in <#CJYS1DAP5|> channel. Folks there could help you much more likely than in generic <#CAHSN3LDN|> channel.

I haven't played a lot with included build but maybe inside them they are different?

Doesn't need an included build.
In the settings script you can define the project dir of the projects.
So in the settings script you can define a different dir for the root project.

I can't use `buildEnvironment` or so because the project fails during configuration

is it only failing in CI?  Are there CI operations that aren’t configured to run locally?

Yea, it's only in CI after bumping to Gradle 7.4. This is the strangest thing.

ok.  what is the specific error / stack trace?

<https://github.com/apollographql/apollo-kotlin/runs/6424691209?check_suite_focus=true>

It ends with
```aused by: java.lang.NoClassDefFoundError: com/google/wireless/android/sdk/stats/GradleBuildProject$PluginType
	at org.gradle.internal.reflect.ClassInspector.inspectClass(ClassInspector.java:70)
	at org.gradle.internal.reflect.ClassInspector.visitGraph(ClassInspector.java:56)
	at org.gradle.internal.reflect.ClassInspector.inspect(ClassInspector.java:36)
	at org.gradle.internal.instantiation.generator.AbstractClassGenerator.inspectType(AbstractClassGenerator.java:272)
	at org.gradle.internal.instantiation.generator.AbstractClassGenerator.generateUnderLock(AbstractClassGenerator.java:211)
	... 218 more
Caused by: java.lang.ClassNotFoundException: com.google.wireless.android.sdk.stats.GradleBuildProject$PluginType
	... 223 more```

<https://stackoverflow.com/questions/65978260/failed-to-apply-plugin-com-android-internal-application|This> hints at a version incompatibility with android plugin.  Is this relevant to your build script?

It's something like this indeed but I can't explain why it only fails in CI...

are there tasks configured to only run in CI?

ok.  there’s an oddity with how build-logic is used - it a dependency in build.gradle’s buildscript (to get it on the classpath).  The correct way to get it on the classpath is to apply a plugin from build-logic (even if it’s an empty one).  thinking that the classpath is ending up with multiple copies of libraries, perhaps only failing on different platforms (CI) due to ordering within the classpath.

So something like this using dependency substitution isn't reproducible?
```buildscript {
  dependencies {
    classpath("com.apollographql.apollo3:build-logic")
  }
}```

that doesn’t appear to be dependency substitution.  it’s adding a project to the buildscript classpath.  Generally there isn’t a need for buildscript.
Try this in build-logic:
a dummy plugin class
```open class DistributionPlugin : Plugin&lt;Project&gt; {
    override fun apply(project: Project) : Unit = project.run {
    }
}```
…define the plugin in build-logic’s build script:
```plugins {
    `kotlin-dsl`
}
gradlePlugin {
    plugins {
        create("distributionPlugin") {
            id = "cloudshift.gradle.DistributionPlugin"
            implementationClass = "cloudshift.gradle.distribution.DistributionPlugin"
        }
    }
}```
…and apply where you want to expose classes available in consuming build scripts:
```id("cloudshift.gradle.DistributionPlugin")```

that will get build-logic on the classpath of consuming projects w/o using buildscript and the differing classpath/classloader mechanisms there.

The repositories in the buildscript block can be moved to settings.gradle.kts; assuming these are used just for plugins, it would be
```pluginManagement {
    repositories {
    }
}```

Classloaders never cease to amaze :smile: . I'll try that and report back, thanks!

gotta love classloaders :exploding_head: !

We were due for conventions plugins anyways so I guess now is the time...

lol, yea, gives you a good place to start.  see that challenging `subprojects`block in the main build script, would be great to get rid of the cross-project coupling there (allowing project tasks to run in parallel and other goodness)

Turns out the issue was a "bad" Github Action cache entry

This is a bit scary TBH, it means that some artifact wasn't what it was supposed to be... So long for build reproducibility...

ok!  glad you’ve tracked this down.  what was the cache config that went sideways?

Not sure, one of the cache keys managed by <https://github.com/gradle/gradle-build-action>

Setting the cache "write-only" <https://github.com/apollographql/apollo-kotlin/commit/1d454d7a3b37d521fe0f4828f0dd179df2f4f687#diff-15c806aa509538190832852f439e9921a23bec2da81f95ed0e4bf13c14e5b160R51|fixes the issue>

(I'm planning to make it read/write again once this workflow finishes)

For the record, the cache is useful indeed

technically it’s the LifecycleBasePlugin, applied by the base plugin.

I suppose this is one of the few cases where you still have to use `afterEvaluate` . Alternatively, don't use a property but a method: when the method is called is when you actually configure the `gradlePlugin {}`.

Trying to avoid all the `afterEvaluate{}` ...

I did the method "trick" quite a few times to skip using afterEvaluate too

Alternatively I would question the value of abstracting the gradlePlugin extension configuration behind your convention plugin. I get the allure, but trying to hide an extension with an extension doesnt seem to get you a whole lot. 

If a project that applies your convention plugin contains multiple plugins in the same source, then they would need to specify publishing options for one, and then use the gradleExtension themselves to add the additional ones.

If a consumer of the convention plugin has to configure an extension or call some custom method anyways, they might as well configure the extension from Gradle. 

Unless it can be fully hidden and configured for the end users, I wouldn't try to obscure the Gradle model with your own custom model. You are only saving a few lines of code for every user, but at the cost of additional classes and a custom extension model. 

I've tried to do this type of thing for the majority of different Java projects we have at our organization (Gradle plugins, maven jars, applications, etc) and every time I tried to push the convention plugins a little too far, I ended up regretting it.

Fair point. It's only two projects so far but I liked the idea of a single entry point. Without this, it's hard to tell what needs to be configured without extra doc

Like how would consumers know they need to configure `gradlePlugin{}`

How are they gonna know they need to configure myPublishing? Same problem really.

The way I do this personally, is do some extension validation in the afterEvaluate and throw an exception and fail the build with a meaningful error message. I try to avoid afterEvaluate at all costs but i find it's generally fine for validation but it should never be used for configuration.

That's fair. It's only two projects so far using it so I guess it's not too bad

What have you done will work perfectly and it's absolutely fine! Just trying to share some of the things I've ran into and regretted when trying to write convention plugins of my own. 

Just to be clear as well, I'm not saying the convention plugin is a bad idea. It's an amazing one! Just questioning the idea of hiding gradlePlugin with myPublishing

"Fun" fact with the method solution to make lazy stuff: If you reference anything else in that file the extension class (`PublishingOption` above) captures the current context and becomes an inner class so you have to pass "this" when creating it:
```val extension = extensions.create("myPublishing", PublishingOptions::class, this)```

I think I'm just going to drop the `kotlin-dsl` plugin. That's a lot of trouble and<https://kotlinlang.slack.com/archives/C19FD9681/p1652107016526049| extra compilation time> to get a little bit of typesafe accessors

tip: move your `PublishingOptions` class into its own `.kt` file. Not only will it be a true top-level class so you don't need that `this` argument, you can also control its actual name which makes it much easier to `import` from other projects (other plugins building on top of yours, or just projects that want to factor some things with helper methods or whatever)

I'll still move everything to `.kt` I think :)

A tiny bit more verbose but less surprises and less generation of typesafe accessor

I usually only the plugin itself in the .kts, and la the classes I use (Extension, tasks, útils) in .kt

I think the biggest advantage is that my customers or collaborators will understand it better when I don't need the plugin boilerplate, and I use the same DSL they are used to

I ended up with this for my `build-logic/build.gradle.kts`
```plugins {
  `embedded-kotlin`
}

apply(plugin = "kotlin-sam-with-receiver")
extensions.findByType(SamWithReceiverExtension::class.java)
          .annotation(HasImplicitReceiver::class.java.name)```
I'm pretty happy with it, it has a good chunk of the "DSL" parts so that copy pasting "mostly" works (except for top level extensions and configurations)

And it's close enough to "regular“ Kotlin that I don't feel there's too much magic going on.

Also allows me to use Kotlin 1.5 and saves "some" accessor generation so I'm hoping it's a bit faster

But it's mostly myself on the project so yea if more people contribute, that might create some questions as to why the top level extensions do not work

&gt; Does this mean calling getProject() from a task implementation is a bad thing?
I'm no Project isolation/configuration cache expert so take this a grain of salt but yea, I think this is bad (more details in the<https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:requirements:disallowed_types| Gradle docs>)

If you enable configuration cache I think you'll get an error

What extensions do you need from the project?

I only do this for custom tasks with custom extensions. I'm guessing I just need to make properties on the task for the things I need to access, and then wire up the task properties to the extension properties at configuration time.

The doc says this:
```In all cases the reason these types are disallowed is that their state cannot easily be stored or recreated by the configuration cache.```

This gets me thinking that I may be abusing the extension API. I have a lot of Gradle tasks and plugins for deployment logic to AWS, specifically S3 and ECR. 

I have an S3 and ECR extension and each of these extensions have methods for hiding the implementation like "uploadToS3". 

The big issue I keep facing is how to properly mock my S3Client class in my tests as I do not want them accessing real S3. I have recently started using local stack for my integration tests with GradleRunner and I am not mocking anything, but for my unit tests using ProjectBuilder I am able to create a "mock" extension that my task is accessing. Normally I would just create custom classes and have that all in the constructor of my task but since I can't use "MyCustomTask task = new MyCustomTask(mockS3Client)" as new is disallowed for testing tasks. 

Maybe I should just give up on the ProjectBuilder unit tests for my tasks and just rely on good integration testing.

you can have constructor arguments for your custom tasks,
```abstract class MyTask @Inject constructor(
    extension: MyExtension
) : DefaultTask() {
    // ...
}

tasks.register("myTask", MyTask::class, myExtension)```
or get them during configuration

Passing the extension to the constructor looks like it is incompatible with configuration  cache

```@get:Input
val allTests: Property&lt;Boolean&gt;
    get() =
        objects
            .property&lt;Boolean&gt;()
            .convention(allProjectsExtension.install.get().preCommit.get().allTests)```


try `.map { ... }` instead of `.get()...`?

with `map/flatMap` I am getting a `Provider&lt;Boolean&gt;`  instead of the property

```allProjectsExtension.install
                .flatMap(InstallOptions::preCommit)
                .flatMap(PreCommitOptions::allTests)```

you can pass a `Provider` into `Property.convention()`

```@get:Input
val allTests: Property&lt;Boolean&gt;
    get() =
        objects
            .property&lt;Boolean&gt;()
            .convention(
                allProjectsExtension.install
                    .flatMap(InstallOptions::preCommit)
                    .flatMap(PreCommitOptions::allTests)
            )```

that still fails with configuration cache :disappointed:

why is it a computed getter? it only makes sense as a stored property, I would think

either that or you don't need to configure it on the task separately from the extension, in which case Provide should be enough and drop all the stuff wrapping it to Property

not sure about what you mean with the last statement

using Provider as input instead of Property?

Sorry, I was configuring something wrong, anyway moving it to Provider is cleaner and it works, thank you!

what I meant was that, regardless of configuration caching, a getter returning a new property on each invocation doesn't make sense. either your task should have a `Property` which is created *once* (if you want to configure it separately per task instance) or should not use a `Property` (if it's only ever derived from other values)

Just a random thought: if adding --scan doesn't change the classpath is because you already have the gradle-enterprise plugin in your classpath

It's the weirdest thing. Adding `--scan` always changes the classpath

But somehow the classpath of "included + --scan" == "standalone"

Can I get more info about the classpath than just a hash?

For a task I guess you could print the files in a doFirst (but I don't know if there is a better way)

This classpath is not an input property or anything like that though. It's the buildscript classpath

:thinking_face: you said its "compileKotlin" task, so it's a task, but yes, a task to compile the buildScript..

I think it's the "classpath of the task itself" vs the "compile classpath that the compiler will use", if that even makes sense?

The only thing that happens before that could be the settings.gradle

The other option would be writing a reproducer and the maybe you can get some help

Yep, makes sense. I'll try to see how to isolate this :thumbsup:

Yes.  Use Java 17, as noted.  It appears the `fabric-loom`plugin requires it.

<https://github.com/FabricMC/fabric-loom/blob/dev/0.12/bootstrap/src/main/java/net/fabricmc/loom/bootstrap/LoomGradlePluginBootstrap.java> that plugin demands Java 17+, and Gradle public releases don't run on Java 18 yet, so you need Java 17 exactly

how to get Java will depend on your system setup but is not in any way Gradle-specific. you should be able to find instructions if you just look for them.

<https://github.com/gradle/gradle/issues/16929|https://github.com/gradle/gradle/issues/16929> is the only one I know of

We havn't encountered any issues when moving to included builds for buildSrc in the elasticsearch build. worked like charm

Was there perhaps some other limitation related to version catalogs? Something like version catalogs not being accessible from within included builds?

referencing version catalogues from included builds is pretty well documented.

Ok so
```  versionCatalogs {
    create("libs") {
      from(files("../gradle/libs.versions.toml"))
    }
  }```
Works within included builds too, right?

You are importing a file. Doesn't matter from where you do that.

Ok, you convinced me :slightly_smiling_face:
Opening another thread for this: <https://gradle-community.slack.com/archives/CAHSN3LDN/p1652704917689839>

Is there a specific reason (or reasons) to move from buildSrc to included build?

`buildSrc` runs always before the build, an included build only if it really is referenced
`buildSrc` result is prepended to the build script class path of all main build build scripts and thus also invalidates all tasks up-to-dateness or cache entry if anything changes, included build is only on the classpath of the build scripts where it is used
`buildSrc` always also runs the tests, included build only runs the necessary work, that is builing the `jar`
`buildSrc` iirc cannot include other builds, included builds can
`buildSrc` is fixed where it is, included build can be wherever you like, like for example `gradle/build-logic`
....
to just name a few

Hmm, we use buildSrc for a lot of standard layout setup stuff. Do the gradle docs recommend moving from buildSrc to includeBuild?

Some Gradle employees or former employees do so though, and I do so. :slightly_smiling_face:

I'm beginning to think we should just place our standard layout stuff into a published convention plugin, and remove buildSrc by default.

<https://developer.squareup.com/blog/herding-elephants/|https://developer.squareup.com/blog/herding-elephants/> mentions doing that

Yeah I did find <https://publicobject.com/2021/03/11/includebuild/> on the topic

But I see the square blog explicitly calls out moving away from buildSrc and includeBuild

I didn't read it, what does it say to move to then?