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

Gradle Community

possibly that project's `gradle.properties` `org.gradle.jvmargs` requires more memory than your computer has available

Hi everyone, I’m trying to define a custom `Configuration` and collect some meta data from those dependencies that are added with it (must be Android AAR package). for example:

```val caliperDependenciesConfiguration = project.configurations.maybeCreate("caliper").apply {
    description = "..."
}

project.tasks.named("preBuild").configure {
            doLast {
                logger.lifecycle("preBuild doLast!")
                val attributesAction =
                    Action&lt;AttributeContainer&gt; {
                        attribute(AndroidArtifacts.ARTIFACT_TYPE, "android-java-res")
                    }
                val size = caliperDependenciesConfiguration.incoming
                    .artifactView {
                        this.lenient(true)
                        attributes(attributesAction)
                    }
                    .artifacts
                    .artifactFiles
                    .files
                    .size
                logger.lifecycle("preBuild $size")
            }
        }```
However it does not work as expected,  any ideas about what’s wrong with above code snippet? Or at least how does it work in Java projects to collect dependencies data? Much thanks!

easiest hack is to write your code somewhere other than `src/main/java/**`, create a task that copies it with modifications, and add the task to `sourceSets.main.java.srcDir()`.
second easiest hack would be similar, but leave the code in `src/main/java/**` and use `sourceSets.main.java.setSrcDirs()` so that it doesn't try looking there in the first place.
(this is liable to confuse the IDE, but if that's what you gotta do…)

No, what you do should work fine as far as you showed details.

Maybe your program detects that no terminal is attached and thus does not produce output or whatever. Hard to guess with that little information :slightly_smiling_face:

OK, alternative question.  I was trying to get a runnable jar so that I could just run it outside of gradle, and added the last section of this file.  But it can't be parsed, with an error on "jar {".

```plugins {
    // This subproject will be an application.
    id 'application'
}


repositories {
    // We will be able to find dependencies here.
    mavenCentral()
}

dependencies {
    // This subproject will be using the musearchtools library (another subproject).
    implementation project(':musearchtools')
    // This subproject will be using the jsoup library.
    implementation 'org.jsoup:jsoup:1.15.3'
    // The tests for this application will use JUnit 4.
    testImplementation 'junit:junit:4.13.2'
}

application {
    mainClass = 'edu.millersville.csci406.spring2023.CrawlerMain'
}

jar {
    manifest {
        attributes {
            'Main-Class': application.mainClass
        }
    }
}```

Imho trying to create a runnable jar is already the worst you can try.
Especially when you already apply the `application` plugin that can build you a proper distribution.

Just remove the whole `jar` block and use the tasks of the `application` plugin like `distTar` or `distZip` to create a distributable archive with your code, your dependencies, and generated start scripts that properly run your application

Ok, thanks, I'll look into that.  And just making my application write its data to a file directly instead of standard out.

Btw. regarding the actual last question about the syntax problem, another personal recommendation, use Kotlin DSL.
You immediately get type-safe build scripts, proper error messages if you mess up the syntax opposed to Groovy DSL, and amazingly better IDE support if you use a proper IDE like IntelliJ.

Then it would maybe be better obvious that you should have had round parentheses, not curly braces after that `attributes` :slightly_smiling_face:

Thanks, I'll do that too.  But as for my immediate needs, I randomly tried adding parenthesis to create `(./gradlew :mucrawer:run 2&gt;&amp;1) | tee crawler.log` and with the parenthesis I *am* capturing all of the output that I want.

Sounds strange.
Those parens you show execute the content in a subshell.
Maybe your shell is somehow configured to suppress some streams or something like that.
(you wouldn't be the first, I've seen it with others before)

So you mean the ABI of B contains more than the intended API?

Maybe it should then not be part of the public API?

But yeah, an intermediate module C could decouple it if that is what you need and want

My intend is to ensure that A is not recompiled when B changes. But I currently noticed that if I already code against a single interface and don't make chnages to this interface - which is the only part of the ABI of B - then A won't never recompile for changes I made in B. Is that correct? If yes I don't actually need the new module except maybe to establish strict boundaries

Yes, if you only change implementations, or things not part of the ABI in B, then A will not recompile.
Well, for Java at least. I'm not sure about Kotlin.

The comment on the import in that example says
```// This is defined in buildSrc```
so I'd say the intention is that you have your own task.

Right. I think that's the comment I missed. And apparently the groovy class I found in the source is doing just that… can't seem to find it in the docs though.

You'll probably have more luck in <#C03EM93810S|>. But gradle is complaining that it can't find a module named `unity-classes` in your project. Without a look at your settings.gradle and the specific line that's failing in your build.gradle file, we don't really have anything to go by...

I figured that out but now while integrating AR in the app, i am facing another error! If you have any experience or idea with that please help me out. <@UMG417LGH>

```from(zipTree(jarTaskProvider))
```
although the manifest might get clobbered, not sure.
in any case, you don't need `dependsOn`

You mean `project.zipTree(jarTaskProvider)`?

```Cannot convert the provided notation to a File or URI: task ':jar'.```

hmm night need `zipTree(files(jarTaskProvider))`

```Cannot convert the provided notation to a File or URI: file collection.```

Seems like using the `archiveFile` directly with `project.zipTree` does the job:
```from(project.zipTree(jarTaskProvider.map { it.archiveFile }))```
Thanks, <@U019L3NM4PK>!

Nah, don't use `zipTree`. With that you first build a jar just to expand it again just to pack it again, that's a huge waste.

Archive tasks are copy specs.
Just do `with(jarTask)` or what it was called.

build.gradle is nothing special, and trouble is that I have multiple modules with the given constelation of plugins, but only this `:foo:bar` throws the warning

```apply plugin: "com.android.library"
apply plugin: "kotlin-android"
apply plugin: "com.google.devtools.ksp"
apply plugin: "com.squareup.anvil"

anvil {
    generateDaggerFactories.set(true)
}

dependencies {
    ...
    implementation deps.moshi.client
    ksp deps.moshi.compiler
    ...
}```

looks like <https://github.com/google/ksp/issues/1294|https://github.com/google/ksp/issues/1294>

ugghh github search, I was just looking through their issues

Things I've tried:
1. specifying the version of okhttp to latest
2. trying to override okhttp version via
```configurations.all {
  resolutionStrategy {
    force("com.squareup.okhttp3:okhttp:4.10.0")
  }
}```


What repositories have you define and where?

It ended up being java version 7 being the culprit. once i updated to 1.8 then everything worked.

what a weird error message from gradle though

There was most probably more information.

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

have you looked into this plugin: <https://plugins.gradle.org/plugin/io.github.dexpatcher.patch-library> ? Seems aimed at your exact use case.

<https://github.com/DexPatcher/dexpatcher-gradle/blob/v2/build.gradle#L116-L127>

OK if I understand this right (I can't find much documentation or use examples fro this DexPatcher), this modified dex files or creates its own or something like that? I was hoping a simple solution exists to my problem, like adding my class under dependencies and moving it on top of the libGDX library or something of that kind. Are you saying my problem can't be resolved with just Gradle scripting in some more elegant way than using a 3rd part library that modifies android packages at source level?

even if it happened to work for you in Eclipse, I don't think the order within a single classloader was ever meant to be specified (you don't have control over the specific order of JARs)

Produce a patched version of the target artifact or use runtime byte code generation (e.g. - with Byte Buddy) to alter the affected classes dynamically.
Or you could use a more conventional approach, replacing or supplementing the functionality of the target classes with code in your application.

since libgdx builds with Gradle, it should be doable to `includeBuild` attach it into your project and patch it locally

It looks in all repositories, but only if the repositories work.
As the plugin central is not accessible, it fails.
Otherwise the build could behave differently / pull in different versions / ... depending on where you build.

how gradle understand that repository not work if he don't check it?

or gradle, regardless of what I specify in the `pluginManager.repository{}`, is looking for in the portalPluginRepository?

You specified both.
It looks in order.
So it looks in plugin central first.
That fails, so it stops.

Hi folks, I have a question regarding a multi-project setup and coverage reporting. I have the following rather simple setup:
```Root project 'gradle-multi'
+--- Project ':app'
\--- Project ':testsuite'```
The `build.gradle` of the testsuite project looks like this:
```plugins {
    id 'java'
    id 'jacoco'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation project(':app')
    testImplementation 'org.junit.jupiter:junit-jupiter:5.9.0'  
}

test {
    useJUnitPlatform()
}```
`:app` contains the class that got testet by a Unit Test from `:testsuite` . The Tests are running fine but the coverage report is empty as it includes only the `:testsuite` project.
Is there is a way to also include the `:app` subproject? I feel like there is a simple way that I am just missing

iirc you can get that error if the project directory is invalid (does not exist - perhaps incorrectly relatively pathed).

Something like this in your build script, covering the relevant projects, may help:
```println(projectDir)
println(project(":plugins:java-core").projectDir)```

the other item to check is that `:common-utils` is included in settings.gradle of eps-spark

```include ":common-utils"
project(":common-utils").projectDir = file("../../jas/common-utils")```
is from eps-store/settings.gradle, but given I can do a `./gradlew clean` here I don't see a problem.

Usually I see this problem with defective relative paths, but I have looked at this so many way, I cannot see that as a problem...

From eps-spark/settings.gradle
```include ':eps-store'
project(":eps-store").projectDir = file("../eps-store")```
looks fine, but that is not what gradle is complaining about.

```eps-spark % ./gradlew clean

&gt; Configure project :
/Users/eric.kolotyluk/git/autonomous-iam/eps/eps-spark
/Users/eric.kolotyluk/git/autonomous-iam/eps/eps-store

&gt; Configure project :elastic-store
Using INDEXER: elastic

&gt; Configure project :eps-store
Using DB: cassandra

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/eric.kolotyluk/git/autonomous-iam/eps/eps-store/build.gradle' line: 73```

```println(projectDir)
println(project(":eps-store").projectDir)```

May help to have the script check for existence from it’s perspective:
```println(projectDir)
println(project(":plugins:java-core").projectDir)
println("Exists : " + project(":plugins:java-core").projectDir.exists())```

Okay, starting to see where the problem is...

```eps-spark % ./gradlew clean

&gt; Configure project :
/Users/eric.kolotyluk/git/autonomous-iam/eps/eps-spark
/Users/eric.kolotyluk/git/autonomous-iam/eps/eps-store
Exists : true

&gt; Configure project :elastic-store
Using INDEXER: elastic

&gt; Configure project :eps-store
/Users/eric.kolotyluk/git/autonomous-iam/eps/eps-store

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/eric.kolotyluk/git/autonomous-iam/eps/eps-store/build.gradle' line: 11

* What went wrong:
A problem occurred evaluating project ':eps-store'.
&gt; Project with path ':common-utils' could not be found in project ':eps-store'.```
In `eps-store/build.gradle`

We can see line 11 in the screenshot

However

```eps-store % ./gradlew clean    

&gt; Configure project :
/Users/eric.kolotyluk/git/autonomous-iam/eps/eps-store
/Users/eric.kolotyluk/git/autonomous-iam/jas/common-utils
Exists : true
Using DB: cassandra

&gt; Configure project :elastic-store
Using INDEXER: elastic

&gt; Configure project :opensearch-store
Using INDEXER: elastic

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See <https://docs.gradle.org/7.6/userguide/command_line_interface.html#sec:command_line_warnings>

BUILD SUCCESSFUL in 741ms```

This is not how I would expect Gradle to behave, and I consider this a defect, but with Gradle, it often does not behave as I would expect...

I don't know any of these options.

But my personal opinion is, that any procedure that requires a specific SCM to build the version string is bad.
Imho if you export sources to a zip, unpack it somewhere, and build, you should get a proper result.
As long as it is just special tasks like release actions that take information to construct a version that is then written to some file that is committed or something like that, that's ok.
But if the version is purely calculated on-the-fly from the VCS and you cannot build without the VCS, then I personally consider that highly questionable.

I usually just have the version in `gradle.properties` and the release tasks remove the `-SNAPSHOT` before release, create a commit, do the release, then increase the patch (or if given another part) version and add `-SNAPSHOT`, then do another commit. And if I do a change that warrants minor or major version increase, then I increase it right before or together with these changes manually as appropriate.

I agree that you should be able to build it on the fly, particularly locally. I think all of these solutions allow that and that is my requirement as well. For my perspective, the versions aren't a huge deal and I don't want those in my code. They seem to result in extra version commits and release commits, and I basically see them as monotony, I think they do. No good to be in code

I've seen a few people's best practices in DevOps to be to not do that and I agree with it. I think the version is an implementation detail, and most of the time you don't care about it. And therefore, having it in the code doesn't matter. You still have the functional code aspects. And you could always override the version if you must

Your approach sounds similar to how I've done it in the past and currently do. Quite frankly, I think it's a terrible approach, it ends up having all of these garbage commits. And then if you have multiple branches, you've got other issues... And at the end of the day the version doesn't matter. Just the code

It also seems to fit better in line with DevOps which is to shift left. And tighter integration with the VCS I think is a decent idea in theory

i do appreciate your discussion though as i try to find the best approach for my problems

I use nebula.release which calculates version from git repo state and has tasks to add release/rc tag. Then build pipeline just use these tags to publish the release

I migrated a project from Maven to Gradle a while back, and I landed on the Gradle Nexus Publish plugin (<https://github.com/gradle-nexus/publish-plugin>) and the Allegro Axion Release plugin (<https://github.com/allegro/axion-release-plugin>). These most closely resembled the Maven plugins I'd been using previously, which made the transition a bit easier. There may be more Gradle-y approaches, but this combination has been working for me.

Yup, I have liked axion, seems to work well. Btw what do you use for maven settings? Do you have info on what happens to settings.xml with Nexus security, or... is there a more gradle friendly way?

AFAIK, `settings.xml` and `toolchains.xml`  are fully supported. I have the paths to several JDKs and the credentials for publishing releases thru Sonatype OSS specified in these files. Also, I'm able to post updates to version references in my README file on GitHub as part of the release process.

the configuration you want to affect is not any of `configurations`, but rather `buildscript.configurations.classpath`

Thanks for the suggestion! Going to try that now

if you have buildSrc, adding the AGP dependency (as a normal dependency,  but a plugin or buildscript dependency) and forcing the GRPC version there will end up in the classpath ahead of all projects' buildscripts

`buildscript.configurations.classpath`  worked like a charm, thanks so much

It tells you the the class and method where this is in the message

And besides that, you can use `-s` to get a stacktrace to the origin of Gradle deprecation warnings

Seeing the following output but not the class &amp; method

```&gt; ./gradlew assemble --warning-mode=all

&gt; Configure project :myAndroidLibrary
Publishing -&gt; com.example:my-android-library:7.4.1
IncrementalTaskInputs has been deprecated. This is scheduled to be removed in Gradle 8.0. On method 'IncrementalTask.taskAction$gradle_core' use 'org.gradle.work.InputChanges' instead. Consult the upgrading guide for further information: <https://docs.gradle.org/7.5.1/userguide/upgrading_version_7.html#incremental_task_inputs_deprecation>

BUILD SUCCESSFUL in 865ms
50 actionable tasks: 50 up-to-date```
Can it happen if a dependency has this issue ?

It’s in the message: `On method 'IncrementalTask.taskAction$gradle_core'`

I can just repeat, it is in the output you showed and you can get a stacktrace if you use `-s`

&gt;  On method 'IncrementalTask.taskAction$gradle_core'

In the specific case of `buildSrc` it indeed is a bit misleading, yes.
But you should always have a settings script anyways and having the root project name defined shouldn't hurt either :slightly_smiling_face:

well for the conventional `buildSrc` having a settings.gradle is often totally redundant

I wonder that it actually still works as at some point it was made an error to have a build without settings script. But I guess `buildSrc` also there has an exception rule as too many builds would have been broken by that.

But it probably still save some CPU cycles to not search further for a settings script.

I understand the point of having a `settings.gradle` file, I'm really commenting about the specific `buildSrc` case. This error was reported by a colleague of mine, and I think it's misleading.

And if I would use `buildSrc` (I usually use inluded builds for build logic), I would probably have a settings script anyway to define repositories, maybe include the version catalog of the parent build, ...

&gt; and I think it's misleading.
Yes, as I said, I think so too in the specific `buildSrc` case, but would just add it :slightly_smiling_face:

I know. And using included builds has quite a few issues (I still cannot use a composite build for multiple Micronaut projects because of many bugs or limitations of composites)

Oh, really? :disappointed:
Didn't hit any problems I remember since quite some time.
I'm curious, what issues do you have?

<https://github.com/gradle/gradle/issues/23633> for example

you can try the project I link here, it's my playground for Micronaut composites. I really wish I could make that work, because it's a nightmare today with having to publish snapshots everywhere.

It is coming from Android plugin.
<https://stackoverflow.com/questions/68472598/after-update-agp-to-4-2-2-from-4-1-3-get-error-execution-failed-for-task-ap> suggest you should update the Android Gradle plugin

I'm using the last stable one gradle-7.6-bin

Do you talk about :
```classpath 'com.android.tools.build:gradle:7.4.1' ```

It's the same, I'm using the last stable one 7.4.1
<https://mvnrepository.com/artifact/com.android.tools.build/gradle?repo=google>

Then I'd suggest you open an issue in the Android Gradle Plugin bug tracker if noone has an idea. You can also post a link to this question to <#CJYS1DAP5|> in case someone there has some insight.

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

Thanks. Why do I always get issues going deeper into Gradle mechanism? :D

Because no software is bug-free or feature complete and Gradle is a big mighty piece. And as uncle Ben says, with great power comes great responsibility. :-)

Yes, absolutely true. And I am glad to have this mighty tool :D
Btw after reading some comments of you regarding this isse: the plugin block is isolated and executed in a dummy project. This also applies to the buildScript block, doesn't it? So this is the same reason why versioncatalogs are also not available, is it?

Yes, the buildscript block is also extracted and handled specially.
Needs to be as it defines the dependencies for compiling the rest of the build script.

It is the reason why my hack does not work in the plugins block, yes.
The normal supported version catalogs are usable in plugins blocks without problem.

Okay, but now I am even more confused. "Why" can I use the normal version catalog but not the versioncatalog extension?

Where? In a precompiled script plugin you can use neither.

In a normal/plain project without any deps/included builds

You do not have access to the project and it is an extension on the project

And the accessors are generated specifically so that they are available

Well up to and including 8.0 it is halfway an accident that it works in the plugins block which is also why IntelliJ shows it as error.
With Gradle 8.1 it will be properly supported.

&gt; You do not have access to the project and it is an extension on the project
:exploding_head: Ahhh, got it. So this is the reason why the workaround with `afterEvaluate` works accessing the extension: The script itself has no access to the project, but the action is stored and executed later with project context.

So I have to wait for 8.1 RCs (or use nightly versions) :D

&gt; With Gradle 8.1 it will be properly supported.
Or do you mean IDE support?

Properly supported by Gradle and thus not showing error in IDE. But besides the IDE error it is already fully working, even with it being by accident.

Please speak English.
But as I have seen "flutter", maybe right away move to <#C03EM93810S|> or maybe even a Flutter community if the question is not Gradle releated as it seems.

Yes, that gives it to the Gradle process.
You cannot directly give system properties to the `run` task.
You need to configure that from your build script.
You can for example read the system property and forward its value, or you could also define Gradle property you forward as system property.

You can pass command line arguments though, with the `--args` option.

Which does not help though to set system properties

No, just thought I’d mention it, if it somehow helped with the end goal

Is there a way to create a JavaExec task that uses exactly the same config as the application's run task and just add some JVM arg there?

Something similar to this?
```val runModified by tasks.registering(JavaExec::class) {
    copyConfigurationFrom(tasks["run"])

    description = "Modified"
    jvmArg("-D…")
}```


Not that I'm aware of, you need to configure it yourself. But you can look at the application plugin how it configures it

If you do those lines in a precompiled script plugin, then `apply false` is useless, it is actually ignored and the plugin is applied. There is an issue that this should instead error out instead of just ignoring it.

It also does not make sense, as `apply false` would be for adding the plugin to the script classpath, but when working on a precompiled script plugin, you add the plugin to the classpath by depending on it in the build script of the build that builds the plugin.

If it's not being pulled from `buildSrc` then would it get pulled in via a composite build? This is happening in the root build.gralde of a composite build, so Kotlin is being added to the classpath before this line somewhere, I assumed it was `buildSrc` since that's what was recently changed, so I believed it was being added by the Kotlin DSL in that script plugin.

Whether `buildSrc` or from a composite build does not change much in that regard.
If the project you depend on has a dependency (other than `compileOnly` or similar) it will be on the classpath of the consumer, yes.

Sorry to clarify it's not in the consumption of the composite project it's failing, but in the composite project itself:
```├─buildSrc
│  └─build.gradle.kts (uses kotlin DSL)
├─myCompositeProject
|  └─build.gradle.kts (failing to apply kotlin plugin due to it already being in classpath)
├─build.gradle.kts```

But still, if `myCompositeProject/build.gradle.kts` has a dependency on the Kotlin plugin so that your precompiled script plugin can use it and you apply it in the plugin with version, it is wrong. And `apply false` is wrong in that case anyway.

It's not being applied for the script plugin, it's being applied for subprojects of `myCompositeProject`, outside of the DSL `buildSrc` does nothing with Kotlin.

So `apply false` was being used to set the version for `myCompositeProject/project1/build.gradle.kts`

Can you provide an MCVE, so that we don't talk about different things?

I'll try, I've been having issues reproducing the issue in anything but the publish task for some reason.

I found the issue and it's actually completely unrelated it looks like at some point this was no longer made a composite build. So much of what I said is no longer correct.

Can you try `8.0 RC3`? This comes with a newer Kotlin version, maybe the problem has been fixed there.

That's a problem of the Kotlin Gradle plugin that does not call `usesService`, isn't it?
So newer embedded Kotlin version will not help, will it?

With RC3 it looks the same: <https://scans.gradle.com/s/qfa7skeppyvly/deprecations>

Kotlin Gradle Plugin 1.9 will fix this, there they added the missing `usesService` calls in commit `278229d2face0`, is that enough for you or do you need some workaround now?

I think it would be nice that, if I just use `kotlin-dsl`  (the plugin embedded in Gradle), I don't get deprecation warnings. As a user, this feels like I am using only Gradle core.

I assume this will be "fixed" the in 8.1 by updating the Kotlin plugin to 1.9?

(It's not blocking me. I just wanted to give this feedback.)

 And if there is a good workaround for 8.0 that I can share with others (that does not give me a different warning) I am also happy to hear it.

Yes. Unless I did something stupid (which I won't rule out completely :sweat_smile: ). It's: <https://github.com/jjohannes/idiomatic-gradle>

&gt; I assume this will be "fixed" the in 8.1 by updating the Kotlin plugin to 1.9?
I doubt it will be available by then :smile:

I wonder that it even builds when you use Gradle 8.
Wasn't that deprecation to be error in Gradle 8? Or was it to be error in Gradle 9?

No the deprecation is new with 8. With 7 I don't get it.

I think the deprecation should be there in Gradle 7 already, but I guess the Kotlin plugin for the embedded Kotlin version in Gradle 7 does not use services and the embedded Kotlin version in Gradle 8 does.

I'd report it to Gradle as regression in 8

Maybe they can somehow get the respective services and do the `usesService` calls as work-around.
Which you might also be able to do manually in your build.

I can do that. I am just surprised. Gradle's integration tests (e.g. for gradle init) should have caught this.

Mh. I don't get this for a simple project. Must again be some weird combination of things :confused:

We expected all build services usages to be properly declared in kotlin 1.8.10.

We did not see that warning in our test suite nor usages.

I assume something special in your build is triggering that codepath in KGP.

There's about nothing we can do about it though :confused:
Rolling back to Kotlin 1.7 because of that would be really bad.

Is the warning only showing up when using the stable configuration cache build feature?

According to <https://youtrack.jetbrains.com/issue/KT-52149> it was fixed for 1.8.20 and 1.9.0, but not 1.8.10

I switched to Gradle 8.0-rc-3 in my almost empty play project and did `:build-logic:compileKotlin` and immediately got
```Build service 'variant_impl_factories_1150915352' is being used by task ':build-src:compileKotlin' without the corresponding declaration via 'Task#usesService'. This behavior has been deprecated. This will fail with an error in Gradle 9.0. Declare the association between the task and the build service using 'Task#usesService'. Consult the upgrading guide for further information: <https://docs.gradle.org/8.0-rc-3/userguide/upgrading_version_7.html#undeclared_build_service_usage>
Build service 'org.jetbrains.kotlin.compilerRunner.CompilerSystemPropertiesService_1150915352' is being used by task ':build-src:compileKotlin' without the corresponding declaration via 'Task#usesService'. This behavior has been deprecated. This will fail with an error in Gradle 9.0. Declare the association between the task and the build service using 'Task#usesService'. Consult the upgrading guide for further information: <https://docs.gradle.org/8.0-rc-3/userguide/upgrading_version_7.html#undeclared_build_service_usage>
Build service 'org.jetbrains.kotlin.gradle.incremental.IncrementalModuleInfoBuildService_1150915352' is being used by task ':build-src:compileKotlin' without the corresponding declaration via 'Task#usesService'. This behavior has been deprecated. This will fail with an error in Gradle 9.0. Declare the association between the task and the build service using 'Task#usesService'. Consult the upgrading guide for further information: <https://docs.gradle.org/8.0-rc-3/userguide/upgrading_version_7.html#undeclared_build_service_usage>
Invocation of Task.project at execution time has been deprecated. This will fail with an error in Gradle 9.0. Consult the upgrading guide for further information: <https://docs.gradle.org/8.0-rc-3/userguide/upgrading_version_7.html#task_project>```

&gt;  Is the warning only showing up when using the stable configuration cache build feature?
Yes. That's it I think. Thanks! Missed that this was also just turned on in the project :grimacing:

That makes sense I guess. All good then from my side.

Yes, `build-src` does not have the feature enabled, but the root build has.
If I comment it out, no warning is shown. if I comment it back in, the warning comes back.

But as the docs suggested to enable the feature as soon as possible on all builds, it is likely this will happen for many users out there I guess.

Yes, but that's fine. Configuration cache is still incubating at this stage.

Don't cry, it'll be marked as stable sooner than you might think :slightly_smiling_face:

When the hackathon was, it was said 8.0.
But I've seen somewhere it should be 8.1 now.

I think what was said was 8.x.
And yes this is scheduled for 8.1 now.

We never tied marking it stable to a major version.

```tasks.compileKotlin {
    usesService(org.jetbrains.kotlin.gradle.plugin.VariantImplementationFactories.getProvider(gradle))
}```
:slightly_smiling_face:

thanks for this discussion - had been seeing pages of warnings/stacktraces going by on 8.0-rc*, hadn’t had a chance to get around to them yet - glad to see this will be fixed soon and can be worked around.

Now to figure out the remaining two related warnings:
```Build service 'org.jetbrains.kotlin.compilerRunner.CompilerSystemPropertiesService_1310369408' is being used by task ':plugins:base:compileKotlin' without the corresponding declaration via 'Task#usesService'. This behavior has been deprecated. This will fail with an error in Gradle 9.0. Declare the association between the task and the build service using 'Task#usesService'. Consult the upgrading guide for further information: <https://docs.gradle.org/8.0-rc-5/userguide/upgrading_version_7.html#undeclared_build_service_usage>
Build service 'org.jetbrains.kotlin.gradle.incremental.IncrementalModuleInfoBuildService_1310369408' is being used by task ':plugins:base:compileKotlin' without the corresponding declaration via 'Task#usesService'. This behavior has been deprecated. This will fail with an error in Gradle 9.0. Declare the association between the task and the build service using 'Task#usesService'. Consult the upgrading guide for further information: <https://docs.gradle.org/8.0-rc-5/userguide/upgrading_version_7.html#undeclared_build_service_usage>```

Probably similar to the one I looked up in source. :slightly_smiling_face:
Or you wait for 1.8.20 where it is fixed or disable the stable configuration cache feature. :slightly_smiling_face:

It's also possible the gradle daemon is using a cached build.

`gradlew --stop` then remove all your build directories

Thanks for your reply.
Ive run `./gradlew --stop` -&gt; clean -&gt; build. No luck. same error message

I would try deleting your `build` directories, maybe there's something that clean isn't getting.

Or maybe you use some libraries that require Kotlin 1.8 also in your main branch now?
What is the whole error message, doesn't it tell who / what exactly is the problem?

I should mention that i also recloned the repo and still getting the same message

Maybe if you wipe out the caches in `&lt;GRADLE_USER_HOME&gt;`?
Everything that is not put manually there like `gradle.properties` or init scripts.

that the full message:
```e: /Users/roi/Git/project/src/test/kotlin/MyClass.kt: (155, 56): Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
The class is loaded from /Users/roi/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.8.0/1796921c7a3e2e2665a83e6c8d33399336cd39bc/kotlin-stdlib-1.8.0.jar!/kotlin/Unit.class```

Oh, ok, that's the Kotlin stdlib, not your classes.
Do you get that when compiling through Gradle or when compiling through IDE?

Somehow you compile against Kotlin 1.8 stdlib while trying to compile with / for 1.6

Im running the build task in the intellij gradle bar

Well, you need to find out why kotlin-stdlib makes it into your compile classpath. Something like `./gradlew dependencyInsight --configuration testCompileClasspath --dependency org.jetbrains.kotlin:kotlin-stdlib` should probably help

this is what i get when i do that:
```FAILURE: Build failed with an exception.

* What went wrong:
Configuration 'testCompileClasspath' not found in configuration container.```

Is it a multi-project build?
Call the `dependencyInsight` task on the project where the problem is

thanks! the insight did reveal from where the dependency comes from. Deleting the maven local did the trick.

Yeah, Maven Local is a broken-by-design crap and should be avoided as hell :smile:

Like this:  `public abstract class ReleasePlugin @Inject constructor(private val layout : ProjectLayout) : Plugin&lt;Project&gt; {`

that’s for a plugin but available wherever you create managed objects via extensions.create or objects.newInstance.

`ProjectLayout` does not contain the `project.path` though

Of the unique ID for the task name, given `":my-project:abc:taskName"`

I want `":my-project:abc"`

ah i see.  that can’t be injected, to my knowledge.  but you can set it as a convention on an extension property in a plugin (or likewise on a task property).
e.g. `ext.myProp.convention(project.path)`

It’s all possible to inject other constructor parameters via extensions.create, which could be used to provide project.path in the extensions constructor.  More info: <https://docs.gradle.org/current/dsl/org.gradle.api.plugins.ExtensionAware.html>

You scrolled over the actual error, scroll up.
Btw., there is also <#C03EM93810S|>

Please can you help? I'm not actually seeing the error. How can I solve this? I'll appreciate.

I have no idea about Flutter.
What is there if you scroll up?

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

<@URQ797WRW> i feel so dumb right now… thank you! I will keep in mind this for future issues

Yes, you can do that in a settings script.
Or you just use the conventional default path for the version catalog which is `gradle/libs.versions.toml`, then you don't need the snippet at all. :slightly_smiling_face:

thanks for the quick response, i don’t think i provided enough information.  We operate with a monorepo and have various separate projects and try to isolate shared logic into plugins (and sometimes init scripts).  We want to share version of common libraries between all of the projects.  What we do today is copy and paste that block which refers to a common location in the mono repo.  However, i need to add that block to each project.  I’m asking how to reduce that duplication

Yeah, you can use a settings plugin for that.

i have heard reference to that in various stack over flow.  is there a specific gradle doc on that? i haven’t been able to find one with google

a “settings plugin” how is that different from a non-settings plugin which i have created

If we are talking about a "normal" plugin, it is `Plugin&lt;Settings&gt;` instead of `Plugin&lt;Project&gt;`.
If we are talking about a precompiled script plugin, it is `foo.settings.gradle.kts` or `foo.settings.gradle` instead of `foo.gradle.kts` or `foo.gradle`.

excellent.  we typically do precompiled scripts, so i’ll dig into that.  thanks you

Example where this is done in a settings plugin:
<https://github.com/jjohannes/idiomatic-gradle/blob/main/gradle/settings/src/main/kotlin/com.example.repositories.settings.gradle.kts#L13-L16>

And here we were just discussing even more options on how to structure such things:
<https://github.com/jjohannes/idiomatic-gradle/issues/4#issuecomment-1424765246>