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

Gradle Community

depends on what you need from the extension.  If it’s just properties, those can be chained and values will be resolved later.  If it’s more than that, one option is to use an observer pattern (NamedDomainObjectContainer.whenObjectAdded is one example).

there isn’t a clean way to know that the extension is configured.  Your approach will work in some cases - but fail when the consumer configures the extension multiple times.

everything in all extensions are plain values, no properties

Also your approach only works for usage in Kotlin DSL. If that is enough for you it might be ok of course, if it indeed takes precedence over the generated accessor.

If you want it for both DSLs properly, you can for example wrap the whole thing another level like
```myExtension {
    configure {
        ...
    }
}```

`configure` is a method of your extension in which you can verify that it is only called once and in which you can do your logic after applying the given closure

I thought about that but it looks ugly and I would add one more level of nesting and it already has a lot

But it is the proper way if you want a clean way.
As I said, if you only need to support Kotlin DSL and your solution works, it might be ok.
Maybe with an added check for multiple-invocation too.

There is no built-in way to be notified about an extension being configured, especially as that could also happen multiple times.

Personally I use my plugin in Kotlin, but it will be open source, if I could support Groovy without nesting should be great

should be great an API for this, as adding a nested extension is simpler to check if it is being called multiple times but the initial one is limited

the `afterEvaluate` is the only solution which can work with Groovy users without having an additional nesting?

Not sure if that can be very problematic tho, because currently my extension is just creating a huge state which is later mapped and configured, so the new configuration would be in the `afterEvaluate`, and that can be problematic with third party plugins I guess

`afterEvaluate` is not a solution but a hack and one that will fail on you as soon as someone configures the extension in an `afterEvaluate` block that is evaluated after your `afterEvaluate` block.
The only thing `afterEvaluate` does, is doing symptom treatment, delaying a problem to arise later again, but that time even harder to debug.
It always introduces nasty race conditions you cannot really avoid except by not using `afterEvaluate`.

_“Friends don’t let friends use `afterEvaluate`”_ :wink:

I usually use a Property if its configured in buildscript, or do plugins.withType targeting the plugin that configures the extension, if its configured by a plugin. Also, try to only read extension properties in the task execution phase, not configuration phase, if possible

&gt; or do plugins.withType targeting the plugin that configures the extension, if its configured by a plugin. 
&gt; 
If that plugin is not using `afterEvaluate` in which case it would break, also if it in a later version adds `afterEvaluate` for some reason, so there is a risk also with this approach. :-)

My 2ct:
Included builds are for substituting binary dependencies.
Something that you could also publish to a repository and use from there instead.
So if you want to use something from the included build, then make it published as proper variant and you should be able to use it.
Depending on a configuration of a project is just a shortcut to be used instead of proper variant publication within a multi-project build, but not cross-builds.

Thanks! Because I'm just following up on this for one of the issue commenters, could I please ask for you to share your thoughts on the GitHub issue also?

I have no idea about artifactory.
But from what I see from a very quick look, the plugin adds a task called `artifactoryPublish` that you are configuring there.

This should also fail in Groovy DSL if there is no such task as soon as this build script is evaluated.

Can you provide an MCVE where you show what exactly you have with the Groovy DSL?

Thanks for catching that. I updated the code above. The groovy dsl is wrapped with a if condition that becomes true on CI builds.

Ah, ok then it should be something like
```tasks
    .withType&lt;ArtiractoryPublishOrWhatTheTypeOfTheTaskIs&gt;
    .matching { it.name == "artifatoryPublish" }
    .configureEach {
        publications(...)
    }```
where you can even omit the `isCI` check, as it is only done if a task with that name and of that type is found.

Do not omit anything like not doing the type-check and directly matching on the name or you will totally break task configuration avoidance as all tasks going through `matching` have to be realized. Like it is written at least only tasks of the specified type are always realized if present.

But don't I need the plugin imported for the script to compile here

`tasks.withType&lt;ArtifactoryTask&gt;`  

Shouldn't I have to import the ArtifactoryTask here?

You need it in the class path, but you don't need to apply it

If you even must not have it in the class path (pretty stupid arbitrary restriction imho if that's the case),
you could resort to using `withGroovyBuilder` for example, or writing that logic in a Groovy file that you `apply from`.
But actually that'a a sacrifice imho.
One of the big pros of the Kotlin DSL is, that it is typesafe and provides proper IDE support.

The same problem happens when running the build with `gradle` instead of `./gradlew...` using the same version (`7.4.2` from <http://sdkman.io|sdkman.io>)

Are there any other things I can remove from my machine to get a fresh Gradle state? Same for Gradle Enterprise.

Only idea the comes up right now, debug the test to find out why it reports a missing bean to maybe find the real problem that way.

Ah, good point. I've tried:
• setting a breakpoint in the `@Configuration` class -&gt; doesn't break
• adding `<http://logger.info|logger.info>("...")` -&gt; doesn't log
• adding `println("...")` -&gt; doesn't print
• the class is clearly there, also in the JAR
• the class file is present in the built JAR
• the built JAR gets a new timestamp on build

Well, hard to guess from here.
Maybe try a method breakpoint instead of a line breakpoint.
In some situtations they work while the others don't.

Thanks again. That didn’t work either though :disappointed: . I’ve wiped my machine and reinstalled MacOS. Not sure what caused all of this though…

Hi, assuming this is a configuration cache issue, please use the <#C013WEPGQF9|> channel where you'll have more chance to get some help

According to <https://github.com/cucumber/cucumber-jvm/blob/main/core/README.md> it should be `cucumber.features`.

Error says:
```Could not resolve all files for configuration ':testCompileClasspath'.
   &gt; Could not find io.cucumber:cucumberjava:7.2.0.```
that means that library `io.cucumber:cucumberjava:7.2.0` was not found. You should probably add
```repositories {
   mavenCentral()
}```
to your build script.

Hello Anze, thanks! But I have changed format dependencies like that

testImplementation group: 'io.cucumber', name: 'cucumber-junit', version: '7.0.0'

        implementation group: 'io.cucumber', name: 'cucumber-java', version: '7.0.0'

}

From error:
```Could not PUT '<https://gitlab.com/api/v4/projects/numOfProjectXXX/packages/maven/com/xxxYYY/nameOfProject/nameOfLibrary/0.1.4-beta04/nameOfLibrary-0.1.4-beta04.aar.sha1>'. Received status code 500 from server: Internal Server Error```
It looks like Gitlab has issues and returns 500. 5xx errors are server errors. So maybe Gitlab has issues or it has changed the API.

Such "disappeared unexpectedly" are usually as the error suggests cases where the daemon was killed or crashed. Because of that you usually do also not find anything useful in the daemon log that could explain it.

The only instances where I have seen this happening so far, were indeed the Linux OOM killer that thought it should kill the process, for example because RAM was low, or the Daemon requested more RAM as was assigned to a Docker container as Java used to calculate the available RAM wrongly (from the host system, not the container). You would find such incidents in the OS logs instead that tell you that it killed process X for reason Y.

Right, tricky since the pod is deleted once the command is finished and the container logs will not contain what I need. But thanks, I'll see what I can find in that area.

We have just seen an increasing number of daemons being killed in our CI environment. And the actions to get any kind of logs have not given anything yet. Anything you can suggest <@URQ797WRW>?

Nope, sorry. If the CI environment kills the daemon you have to investigate with the CI.

To make it even funnier, adding --debug to the daemon makes it finish correctly and not disappearing :/

Who knows, maybe generating that much output makes it that significant slower that the RAM is not used in such a high rate and thus it is not killed by OOM killer or something like that. :man-shrugging:

It looks like a bug in the daemon, but it is hard to say. More likely a bug in a 3pp plugin I assume. Spotless is a possible culprit in that case since that plugin reports a build error when I use --debug.
In that case, allowing a plugin to crash the daemon is not good either.

Memory looks quite OK, performance tab in the scan says:
G1 Old Gen	278.5 MiB/4 GiB (6.8%)

Well any plugin could theoretically do `System.exit(0)` or doing something to crash the JVM.
Nothing Gradle could really do about that. (Yes, I know `System.exit` could be prevented with a security manager, but a plugin should just not do that :-D)

Now failing again. Last line of daemon log (when using --debug flag) is from findbugs. Getting closer...

Workaround/Solution? Spotbugs (which use findbugs classes) plugin have some indications online that it cannot be run in parallel. So I broke out those tasks and ran them using --no-parallel flag. Now finally it seems stable.

Still (hint: Gradle) capturing that by an exit hook or by registering/informing about tasks to the client so that the client can report of which tasks that destroyed the daemon would be a good feature.

That information could even go as an alternative build scan to the GE server...

Exit hooks are never guaranteed to run. They should only be used for fallback cleanup stuff, but never for important work. If the JVM is killed, they are not run. If the JVM crashes, they are not run. If one of the hooks needs too much time it is aborted and all pending hooks do not run. ...

Hi Joachim,
It’s good you found a way to stabilise your CI. If the Spotbugs tasks should not run in parallel then the Spotbugs plugin should take care of that. Care to raise an issue to them?
By the way, you can use Gradle features to influence the parallelism of tasks. You can declare that a set of task cannot run in parallel by registering a “shared build service” that does nothing but is registered to the tasks you want to affect, and set its `maxParallelUsages` to 1. That’s exactly what the Spotbugs plugin should do if its tasks can’t run in parallel, you can do that in your build so that you don’t have to split the execution and use `--no-parallel` which affects all tasks.

See <https://docs.gradle.org/current/userguide/build_services.html#concurrent_access_to_the_service>

The Spotbugs execution used to be problematic in the past due to static state used by Spotbugs and so even different projects built by the same daemon influenced each other.

But this is long fixed already. The plugin now (by default) uses a no-isolation worker for parallelism from which it uses `javaExec` for necessary isolation. It can of course happen that you run out of RAM, especially when running many of them concurrently. But other than that I think the SpotBugs plugin should now be pretty safe for parallel execution.

Are you using the latest Spotbugs Joachim?

No <@UABCKNV3K> we are one main version behind in one of our older branches.

Ok. I have no idea when that plugin got stable when running in parallel. It might be worth it to upgrade.

If you cannot update, which version exactly is "one main version behind"?
There was a time where it used process-isolated worker by default which was not good but had a property to use javaexec instead.
With 4.7.0 the hybrid approach, using no-isolation worker for parallelity and in that javaexec for proper isolation was added but was not yet the default, but could be enabled via property.
The hybrid worker is used by default since 5.0.0.

We will look into upgrading, seems like the best way forward. Thanks

afaik there is no way to exclude dependencies or constraints in the publication API. What you can do is define constraints in a separate configuration that you only use for the `*Classpath`  but not the `*Elements`

E.g.:
```val constraint = configurations.create("constraint")
configurations.compileClasspath.get().extendsFrom(constraint)
configurations.runtimeClasspath.get().extendsFrom(constraint)
// or others/more if you have Android or KMP```
And then define your alls constraints on the `constraint` configuration.

yeah, I've read an issue with this solution. Actually we applied constraint too broad, which adds unnecessary `&lt;dependencyManagement&gt;` block in publication where constraint dependency is not used.

So I redo our script to apply constraint only when project has configuration with this constrained dependency.

Legit: <https://melix.github.io/blog/2022/05/gradle-laziness.html>
1st one and 2d are equivalent and eager. 3rd one is lazy.

First two are eager and cause each element to be realized and configured

…still hoping that, someday, Gradle will print deprecation warnings when using eager API calls…

for tasks, yes. For other containers, that's highly debatable.

Doesn't hurt to use it always though, does it?

sure it does: <https://github.com/gradle/gradle/issues/19955>

symptom of broader design issue - an API is exposed but not fully/properly implemented for those containers. :face_palm:

That makes it even more important to have proper guidance when to use what

What I tell everyone atm is:
• Lazy API for `tasks`
• Eager API for all other “Containers” (There is no gain in being lazy for e.g. SourceSets or Configurations and you may run into issues like the one linked above. I think in hindsight, despite good intentions, this was a design mistake.)
But I am happy to be corrected if there is something I miss. Would be great to improve the guidance on this. And yes - deprecate the things that are not recommended anymore.

I meant programmatic guidance. :slightly_smiling_face:

Why would you prefer to apply pugins the legacy way?

When I configure modules with `subprojects` or `allprojects`, I need reference to particular extension or task in root `build.gradle`. For example:

```subprojects {
    afterEvaluate {
        extensions.getByType&lt;KotlinProjectExtension&gt;().jvmToolchain {
            (this as JavaToolchainSpec).languageVersion.set(JavaLanguageVersion.of(sdk.versions.jdk.get()))
        }
    }
}```

Well, any usage of `subprojects` or `allprojects` block is bad too. It immediately introduces project coupling and works against more sophisticated features like parallel execution or configuration cache. So using them is highly discouraged anyway. The proper way to share configuration code is to use convention plugins.

And `afterEvaluate` is also bad in almost all cases where it is used, it is usually only symptom treatment and just delays problem to a later and harder debug point in time and always introduces race conditions as the thing meant to wait for could also happen in an `afterEvaluate` block happening after your `afterEvaluate` block.

Instead you should either apply the plugin in question that you want to configure, or react to it being applied using `pluginManager.withPlugin...`

And btw. the version for a plugin in version catalog is not mandatory, it works fine without, as the docs you linked to also describe

I concede using `afterEvaluate` is a bad and will move on from this practice.

Another reason to use legacy plugin application is if a plugin has <https://blog.gradle.org/optional-dependencies|optional dependency>, I still need to configure the capabilities in root `build.gradle` :

```buildscript {
    dependencies {
        classpath("my.plugin") {
            capabilities { ... }
        }
    }
}```

I would have to disagree with your last statement, declaring a plugin without a version throws an `org.gradle.api.InvalidUserDataException` . As of version 7.4.2, `withoutVersion` is only limited to `LibraryAliasBuilder`.

Why do you disagree?
Even your screenshot confirms what I say.

`PluginAliasBuilder` does not have a function `withoutVersion`, only `LibraryAliasBuilder` does.

Hm, that's probably an omission in the API then.
Using the TOML it works fine to have a plugin without version

And regarding the capabilities for plugins.
I didn't try, but if this really prevents using the `plugins { ... }` DSL it imho is a bug in that plugin that should be fixed.
It should maybe instead have different sub-plugins for the use-cases that you apply additionally.

As a work-around you could probably declare this dependency in `buildSrc` build script in `runtimeOnly` scope.

And regarding without version, you could set some fake version and then use it like `libs.plugins.myPlugin.get().pluginId` to only get the id without version

Is the legacy plugin application in any risk of being removed in the future?

Alright it has been a revelation. Thanks for your time and insights. Have a great rest of the day!

Maybe because of the additional dot in front of the first 3?

Yea deleted everything, but my project file has build script, not sure if that affects it

I'm trying to use convention plugins from buildSrc

You say you have nothing in `buildSrc` but you say you have convention plugin in `buildSrc`, ..., so what is it?

They can both be true, the build failure I posted was with the screenshot

I'm trying to apply groovy-gradle-plugin to use convention plugins in my project

Do you have a convention plugin in your `buildSrc` that you want to compile or not?

Unless you are Heisenberg it cannot both be true

yes in this case, i have a convention plugin staged in `buildSrc/src/main/groovy`

following this structure and guide <https://docs.gradle.org/current/samples/sample_convention_plugins.html#organizing_build_logic>

Is it perhaps as the error indicates - the convention plug-in has a buildscript block?

yea good call, that was not obvious to me. Thanks

Chances are you actual error is higher than what you copy/pasted. Does the kotlin compiler say anything about an error? A line that would start with `e:` 

Hi thanks for your reply, yes it showed some compile error and i just fixed that, now build is success but getting another issue..app terminating immediately after launch it showing error like

`*ERROR*  Error: Exception in HostObject::get(propName:UIManager): java.lang.VerifyError: Verifier rejected class com.facebook.react.views.textinput.ReactTextInputManager: android.view.View com.facebook.react.views.textinput.ReactTextInputManager.createViewInstance(com.facebook.react.uimanager.ThemedReactContext) failed to verify: android.view.View com.facebook.react.views.textinput.ReactTextInputManager.createViewInstance(com.facebook.react.uimanager.ThemedReactContext): [0x4] can't resolve returned type 'Reference: android.view.View' or 'Unresolved Reference: com.facebook.react.views.textinput.ReactEditText' (declaration of 'com.facebook.react.views.textinput.ReactTextInputManager' appears in /data/app/~~PpIuce9cFCSw4_aaWG3J0g==/com.crst-s6ApY9FAsqfr49-qelZaMg==/base.apk)`
 `*ERROR*  Invariant Violation: Module AppRegistry is not a registered callable module (calling startHeadlessTask). A frequent cause of the error is that the application entry file path is incorrect.` 
   `This can also happen when the JS bundle is corrupt or there is an early initialization error when loading React Native.`
 `*ERROR*  Invariant Violation: Module AppRegistry is not a registered callable module (calling startHeadlessTask). A frequent cause of the error is that the application entry file path is incorrect.`

Is there any way to find out programmatically where a property was set (i.e. whether via `-Pfoo`, `.gradle/gradle.properties`, `gradle.properties`, etc)? We'd like to provide a more helpful error message in case a certain property is set wrongly, and knowing where it is set would help.

```Caused by: org.gradle.internal.metaobject.AbstractDynamicObject$CustomMessageMissingMethodException: Could not find method dependencyManagement() for arguments [build_29ulvflvltljlgemnx04tmqjt$_run_closure13@8069462] on root project 'maxcodices' of type org.gradle.api.Project.
	at org.gradle.internal.metaobject.AbstractDynamicObject.methodMissingException(AbstractDynamicObject.java:182)
	at org.gradle.groovy.scripts.BasicScript$ScriptDynamicObject.methodMissingException(BasicScript.java:161)
	at org.gradle.internal.metaobject.AbstractDynamicObject.invokeMethod(AbstractDynamicObject.java:166)
	at org.gradle.groovy.scripts.BasicScript.invokeMethod(BasicScript.java:83)
	at build_29ulvflvltljlgemnx04tmqjt.run(/Users/JHe55/Workspace/nike/xxx/build.gradle:230)
	at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:91)
	... 128 more```

```dependencyManagement()```
is a method defined like it below

I have this after I upgrade springboot from 1.5.6.RELEASE to 2.1.3.RELEASE

So start with, I'd highly recommend to not use the spring boot dependencies plugin if it just for consuming BOMs, but instead use the built-in bom support with `platform(...)`.
That plugin is from a time where Gradle did not have BOM support and it has other features including questionable ports of imho broken-by-design Maven logic into Gradle.
If you don't need any of the additional features of that plugin, just kick it and use the built-in support instead.

Regarding the error, it means something is wrong inside the closure, but there is a bug that it is not displayed in a good way that is hopefully improved with Gradle 7.5. Currently when you get that error you need to comment out all lines within the closure and comment them in part by part to find the fault part, or in your case read the documenation of the plugin you are using to see what you do wrong.

This problem is one of the major reasons I greatly prefer the Kotlin DSL over the Groovy DSL, as you always get proper error messages, have immediately type-safe build scripts and an amazingly better IDE support including code completion.

Thanks for your message, Vampire. I’m finding solution

I'd say it depends.
`buildKotlinToolingMetadata` means "build the kotlin tooling metadata"
`publishToMavenLocal` means "publish to maven local"
But
`checkSpotless` would mean "check spotless", not what it should mean "check my code with spotless". So it would more be `doSpotlessCheck`or to be more succinct `spotlessCheck`. An alternative could be `checkWithSpotless`, but it somehow feels more bulky.

So generally I like it more like `compileJava` and friends, but only if it makes sense and `checkSpotless` would imho not as it would be ambiguous and easily interpreted wrongly.

Task registrations should start with a verb. Task type names should be nouns *not* ending with Task. e.g.
`compileJava` and `JavaCompile`

I'm curious <@UF9HQE743>, would you have called it `checkSpotless`?

no, I agree with you that that would sound like it would be checking spotless.
For check tasks Gradle uses the convention to use the checker as a verb combined with what it is checking, e.g. `checkstyleMain` so I guess I would go with `spotbugsMain`

So `spotlessMain` then, yeah. :slightly_smiling_face:

While I'm still not sure I like that inconsistency.
In most other cases `main` is left out and only added for all other source sets.

You are trying to define a dependency for the `implementation` configuration while the `implementation` configuration does not exist.

ill send you the app gradle and the android gradle

```def localProperties = new Properties()
def localPropertiesFile = rootProject.file('local.properties')
if (localPropertiesFile.exists()) {
    localPropertiesFile.withReader('UTF-8') { reader -&gt;
        localProperties.load(reader)
    }
}

def flutterRoot = localProperties.getProperty('flutter.sdk')
if (flutterRoot == null) {
    throw new GradleException("Flutter SDK not found. Define location with flutter.sdk in the local.properties file.")
}

def flutterVersionCode = localProperties.getProperty('flutter.versionCode')
if (flutterVersionCode == null) {
    flutterVersionCode = '1'
}

def flutterVersionName = localProperties.getProperty('flutter.versionName')
if (flutterVersionName == null) {
    flutterVersionName = '1.0'
}

apply plugin: 'com.android.application'
apply plugin: 'kotlin-android'
apply from: "$flutterRoot/packages/flutter_tools/gradle/flutter.gradle"

android {
    compileSdkVersion flutter.compileSdkVersion


    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }

    kotlinOptions {
        jvmTarget = '1.8'
    }

    sourceSets {
        main.java.srcDirs += 'src/main/kotlin'
    }

    defaultConfig {
        // TODO: Specify your own unique Application ID (<https://developer.android.com/studio/build/application-id.html>).
        applicationId "com.shoppingworld.usersapp"
        minSdkVersion 19
        targetSdkVersion flutter.targetSdkVersion
        versionCode flutterVersionCode.toInteger()
        versionName flutterVersionName
        multiDexEnabled true

    }

    buildTypes {
        release {
            // TODO: Add your own signing config for the release build.
            // Signing with the debug keys for now, so `flutter run --release` works.
            signingConfig signingConfigs.debug
        }
    }
}

flutter {
    source '../..'
}

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
}


apply plugin: 'com.google.gms.google-services'```


```buildscript {
    ext.kotlin_version = '1.6.21'
    repositories {
        google()
        mavenCentral()
    }

    dependencies {
        classpath 'com.google.gms:google-services:4.3.12'
        classpath 'com.android.tools.build:gradle:4.1.3'
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"



    }
}

allprojects {
    repositories {
        google()
        mavenCentral()
    }
}

rootProject.buildDir = '../build'
subprojects {
    project.buildDir = "${rootProject.buildDir}/${project.name}"
}
subprojects {
    project.evaluationDependsOn(":app")
}

task clean(type: Delete) {
    delete rootProject.buildDir
}

dependencies {
    implementation 'com.android.support:support-annotations:28.0.0'
    implementation 'androidx.annotation:annotation:1.4.0'

}```


and this is the error

Launching lib/main.dart on Android SDK built for x86 in debug mode...
Running Gradle task 'assembleDebug'...

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/mac/AndroidStudioProjects/users_app/android/build.gradle' line: 38

* What went wrong:
A problem occurred evaluating root project 'android'.
&gt; Could not find method implementation() for arguments [com.android.support:support-annotations:28.0.0] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at <https://help.gradle.org>

BUILD FAILED in 24s
Exception: Gradle task assembleDebug failed with exit code 1

As I said,
&gt; You are trying to define a dependency for the `implementation` configuration while the `implementation` configuration does not exist.
On the project where you try to define those, dependencies no plugin is applied that would add that configuration.
I guess you wanted to add this to the other build script.

I highly recommend using Kotlin DSL build scripts, because then your build scripts are immediately type-safe
and you have muuuch better IDE support and would e. g. immediately have seen that it is an unresolved symbol.

Btw. just in case you are not aware, your build scritps are sprinkled with bad or legacy practices
like `subprojects { ...  }` blocks, `allprojects { ... }` blocks, legacy plugin application instead of `plugins { ... }` block, ...

thank you for your response
sorry for my ignorance, I'm new to app development.
if I may ask how could I fix this issue or would I need to start all over and use kotkin DSL?

I already told you how to fix it.

And the usage of the Kotlin DSL was just a recommendation to have more convenience and reliability when writing the build scripts, whether you follow it or not is up to you.

TeamCity injects code into tasks of type `Test` to output service messages so that it can show the tests live.
If you make your `JavaExec` task output these service messages too, TeamCity can pick them up.
Alternatively, you can make your `JavaExec` task generate a test report that TeamCity can interpret and enable the XML report build features that then reads it after the task or build has finished.

Thanks! I'll give these things a go. There will likely be follow-up questions lol

If you first go to latest 6.x and fix all deprecation warnings from Gradle, it should usually mostly just work with 7.x

The one I struggle with, is the old repo I tried to add springboot and I couldn't make it work.  The one that works, was to create a new repo with gradle7.3/java8/springboot2.7.0 and just move the src/main and src/test on the old repo.  The build.gradle I need still to add the jcenter() not just mavenCentral() or else the old codes will not work with the dependency.

Your dependency:
```classpath 'com.google.gms:google-services:+```
is picking up the latest version of that plugin. Looks like `4.3.12` was just released yesterday and possibly breaks the API of the `GoogleServicesTask`.
You should hardcode your dependency on `4.3.10`  (apparently there's no `.11`)

you can see the releases here: <https://maven.google.com/web/index.html?q=com.google.gms#com.google.gms:google-services:4.3.12>

I tried to locate the `includeBuild` by the project coordinate inside of `buildSrc`  with `implementation project(":buildtools")` and the error is
```&gt; Project with path ':buildtools' could not be found in project ':buildSrc'.```
Should I be trying to go in the other direction? and if yes, what would the project coordinate be because `implementation project(":buildSrc")` doesn't seem to work

An included build is an included build, not an included project.
Included projects are part of a multi-project build and can be referenced with `project(...)`.
Included builds are own builds and you cannot reference them with `project(...)`, you just reference them by their normal Maven coordinates like any other dependency.

I'm pretty sure I tried both, but thanks for the pointer. I'll give it a try later

Do I need to do any dependency substitution maybe?

Not if your included build is properly set up.
Use it's `outgoingVariants` task and you should see the coordinates you need to use.

looks like it's not supported <https://github.com/gradle/gradle/issues/12978>. I'm getting that same error.

"that same error."? That you cannot use `includeBuild` from `buildSrc`? That is expected.
I just thought it might maybe work like with the plugin, that you included from the root build and can access it from `buildSrc` since the order changed and settings are now evaluated before `buildSrc`.
This was the other way around in older Gradle versions.

if you're referring to <https://docs.gradle.org/6.7/samples/sample_sharing_convention_plugins_with_build_logic.html|sharing the plugin> in `includeBuild` to `buildSrc` , I'm aware that works. The missing piece for me is how to reuse the classes in that plugin as a dependency.

No, I'm not, what you want is exactly what I meant and said

You `includeBuild` in the "parent" settings script and just declare the dependency in the `buildSrc` build.

Alternatively you can of course simple kick `buildSrc`.
I never use it these days, except for exceptional cases like monkey-patching plugin classes.
Besides that I always use an included build like `gradle/build-logic`

oh i see, the `settings.gradle` for `buildSrc`

i would get rid of `buildSrc` eventually.. just will take some time

No, not the settings script of `buildSrc`, you do not listen

There you will just get the exception from that ticket

The settings script of the "parent" build, where you also would include the plugin in the docs you referred to

it's already included in my rootProject's `settings.gradle`

Then you just need to properly declare the dependency as I said multiple times already.

Unless you are on an ancient Gradle version

I tried it witz 7.4.2 and it worked fine.

could you perhaps point to a working example? I'm trying my best and it's not as easy for me as it might be for you :wink:

I don't have one, I just wrote it ad-hoc into my play project and it simply worked.
But I don't know what to show, it is just the two lines.
The `includeBuild` in the parent settings script and the dependency in the `buildSrc` build script with the correct coordinates as can be found as capability in the output of `outgoingVariants` task as already mentioned.
There is really nothing more to it.

this is what I have in `settings.gradle`

```pluginManagement {
    includeBuild ('gradle/gradle-plugin')
}

includeBuild ('gradle/gradle-plugin')```

in `gradle/gradle-plugin/settings.gradle`

```rootProject.name = "plugin"

include(":plugin")
include(":buildtools")```
in `buildSrc/build.gradle`, I tried both the maven coordinates and project

If you don't get it running, you should try to produce an [MCVE](<https://stackoverflow.com/help/mcve>) that shows where you have problems.

ok i'll try to repro in a smaller project and if I can, i'll post to S/O thanks

my error when trying to pull it in using the proper coordinates

```Execution failed for task ':buildSrc:generateSourceRoots'.
&gt; Error while evaluating property 'sourceRoots' of task ':buildSrc:generateSourceRoots'
   &gt; Failed to calculate the value of task ':buildSrc:generateSourceRoots' property 'sourceRoots'.
      &gt; Project with path ':buildtools' could not be found in project ':buildSrc'.```

That does not look like proper coordinates

and seems like this was fixed maybe in Gradle 7.4 <https://github.com/gradle/gradle/issues/18984>

Ah, quite possible then. As I said, I tried with 7.4.2.
Was not aware there was some bug in previous version.

Well, then you either have to switch to an included build or to newer Gradle version.
Both should not be dramatic changes.

turns out you were right all along but I was hitting errors because i'm on Gradle 7.3.3 and even when upgrading to Gradle 7.4.2, I'm hitting an Idea bug that is <https://youtrack.jetbrains.com/issue/KTIJ-20201|fixed here>, but that's a beta version of Android Studio (Dolphin).

I probably can't use this method until Dolphin goes GA. (because large eng org)

Recap as you mentioned
&gt;  The `includeBuild` in the parent settings script and the dependency in the `buildSrc` build script with the correct coordinates as can be found as capability in the output of `outgoingVariants` task as already mentioned.

Can't you update the Kotlin plugin?
It's not fixed in the IDE but in the Kotlin plugin.

oh i see, thanks for pointing that out.. I'll see if that works

doesn't look like I can update the Kotlin Plugin any further than this.

It is already on 1.7.0, that's the latest release, what updates do you expect?

it's still not working in that release i screenshotted. I don't know how IJ versioning works, but I'm assuming I need 213

Fixed in
• IJ 221.1623 (Kotlin 221-1.5.10-release-955-IJ1623)
• IJ 213.6094 (Kotlin 213-1.5.10-release-949-IJ6094)


If it is fixed in 1.5.10, I strongly assume it is fixed in any 1.7.0 version which comes way later

If you reference a class of sqlite-jdbc in your code, then you indeed should have it declared as dependency directly.

That sentence means other cases, where you e. g. want to downgrade a transitive dependency for some reason or upgrade it, but without actually referencing that dependency in your own code. There a dependency constraint is more suitable.

The dependency constraint you tried just controls the version of the transitive dependency, but does not change its scope. That's why it is not applicable in your case anyway.

Awesome, thank you for the clarification.

&gt; ```of type xxx.ManifestService using a provider of type xxx.ManifestService.```
As there is two times the same FQCN, I'd say this is a class loader problem.
Your `ConfigureManifestTask` is coming from a different class loader than your `ManifestService` class and thus it cannot assign it as Java sees the `ManifestService` class the variable has as different from the `ManifestService` instance you give it.

Just set a breakpoint and compare the class loaders and you will most probably see that this is the case.

If you for example have root project `R` and sub-projects `A` and `B`, then apply plugin `X` containing `ManifestService` and `ConfigureManifestTask` to `A` and `B`, then the classes are on different class loaders and thus incompatible.
If then `A` is evaluated it registers the service with its class. Then `B` is evaluated and gets the service `A` has registered which is incompatible with it's own `ConfigureManifestTask`.

The solution would be to somehow add `X` to the class path of `R` as it would then be in a class loader that is the parent of both of the other class loaders and would fix the problem.

I have just tried following scenario: applied plugin `X` to `:R:A` and `:R:B` and run `jar` task from within the `R`. `configureManifest` task run as expected and altered manifests within `:R:A` and `:R:B`. So no problem with different class loaders here. Then I applied spring boot gradle plugin (without any configuration applied) to `:R:B` and tried to run `jar` the same way I did before and bum, the exception is back.

I will try to add `X` to `:R` without applying it..

This fix the issue!!! You saved my day, again. Thank you!
So there must be something wrong with the Spring Boot Gradle plugin - It somehow corupts the classloaders. Will create an issue on their github page.

Actually I wonder it worked without it. :smile:

I'd recommend using tooling API instead. `GradleBuild` has drawbacks like incompatibilities with composite builds for example.

Please do not split topics across several threads.
This makes following the conversation in the threads view very hard as the context of the other messages is missing.
If you have additional information either edit the original message or post to its thread.

Your build is running with Java 1.8 and you tell it to output Java 11 bytecode. That cannot work.

I would recommend looking into toolchains also: <https://docs.gradle.org/current/userguide/toolchains.html>

but why my build is 1.8 ? I have changed it to 11 everywhere before build

as long as you are not using toolchains you will also have to make sure that you actually start the gradle process with JDK in version 11

Hi Louis, Lars
Thank you ! I find the cause. It was JDK 1.8 in gradle configuration as default. I solved it by adding JDK 11 path into gradle.properties

when using a gradle dep scan (online) i can see that the `other-library` is part of the compile and runtime classpath (via library-a)

Yes, `implementation` means it is on the compile and runtime classpath of `library-a` and on the runtime classpath of your project

If that is not the case, either something is misconfigured or you found a bug, but tbh I would wonder if it is a bug that is not yet found. Maybe you can knit an MCVE?

thank you for the answers already! So as expected, the 'app' project (spring boot project) that includes `library-a` does itself not need to include `other-library` in its `implementation`  dependencies - it should be included, also for runtime.

Of course. Would be ridiculous if you were forced to redeclare all transitive dependencies.

Besides that you would use `runtimeOnly` unless you reference code from those dependencies in your own code.

But if so, you would declare it, even if it comes in transitively already

Just to be sure doesnt `implementation` mean, it is only on the runtime classpath on the app? so assuming is have

```dependencies {
  implementation library-a;
}```
in the app

an library-a defined
```dependencies {
  implementation other-library
}```
then other-library will only be on the runtime-classpath off `app`, right?

does the behavior change when i `includeBuild` the project instead of consuming it via the nexus? it seems so

While the project substitution works well for the compile and runtime classpath , it does not work / is not applied to the testCompileClassPath nor testRuntimeClassPath

this means, that running our spring boot tests, the outdated nexus based jar was used, while when looking at the compile/runtime classpath, we could see the proper substitution and all the dependencies

Unless I misunderstood what you mean, it should work fine.
Can you maybe knit an MCVE?
That will also help if you report it as issue.

sorry a reproducer is not just a 5 minutes kind of work - at least for now i would go down that route yet. I can report the issue myself i guess, no problem, fairly sure this is an issue with gradle or 'managing expectations'

You need to report yourself either way if you want it reported.
I'm just a user like you, I'm not going to be your secretary. :wink:

sorry was not sure you are a core developer. Was not implying it anyway

Gradle 6.7.1
`minSdkVersion = 21
        compileSdkVersion = 31
        targetSdkVersion = 31
        ndkVersion = "20.1.5948944"
        kotlinVersion = "1.4.32"
        kotlin_version = '1.7.0'
        dokka_version = '0.10.1'
        appCompatVersion = "1.1.0"      // Or higher.  Required for new AndroidX compatibility.
        googlePlayServicesLocationVersion = "19.0.1"  // Or higher.`

:ReactNative:Running '[node, -e, console.log(require('react-native/cli').bin);]' command failed.

FAILURE: Build failed with an exception.

* Where:
Script '/Users/varmabhupatiraju/Joshi/MyProjects/reactnativecli/crst/node_modules/@react-native-community/cli-platform-android/native_modules.gradle' line: 189

* What went wrong:
A problem occurred evaluating script.
&gt; Cannot run program "node" (in directory "/Users/varmabhupatiraju/Joshi/MyProjects/reactnativecli/crst/android"): error=2, No such file or directory

* Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Exception is:
org.gradle.api.GradleScriptException: A problem occurred evaluating script.
    at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:93)
    at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
Caused by: java.io.IOException: Cannot run program "node" (in directory "/Users/varmabhupatiraju/Joshi/MyProjects/reactnativecli/crst/android"): error=2, No such file or directory
    at java_lang_Runtime$exec$0.call(Unknown Source)
    at ReactNativeModules.getCommandOutput(/Users/varmabhupatiraju/Joshi/MyProjects/reactnativecli/crst/node_modules/@react-native-community/cli-platform-android/native_modules.gradle:189)
    at ReactNativeModules$getCommandOutput$0.callCurrent(Unknown Source)
    at ReactNativeModules.getReactNativeConfig(/Users/varmabhupatiraju/Joshi/MyProjects/reactnativecli/crst/node_modules/@react-native-community/cli-platform-android/native_modules.gradle:233)
    at ReactNativeModules$getReactNativeConfig.callCurrent(Unknown Source)
    at ReactNativeModules.&lt;init&gt;(/Users/varmabhupatiraju/Joshi/MyProjects/reactnativecli/crst/node_modules/@react-native-community/cli-platform-android/native_modules.gradle:84)
    at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at native_modules_7i9ilp1oxc33pac3tz23bifq1.run(/Users/varmabhupatiraju/Joshi/MyProjects/reactnativecli/crst/node_modules/@react-native-community/cli-platform-android/native_modules.gradle:287)
    at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:91)
    ... 159 more
Caused by: java.io.IOException: error=2, No such file or directory
    ... 170 more


* Get more help at <https://help.gradle.org>

BUILD FAILED in 173ms

Some plugin or code in your build script or whatever, requires that `node` is available in the `PATH` which it is not

So it fails when trying to execute `node`