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

Gradle Community

I am creating a Gradle task which run a npm command that doesn't have a defined time to be finished (typical `serve` task for websites). How should I test this task?

Frustrated to find GitHub Packages doesn’t allow unauthenticated access as a Maven repo. 

Can anyone recommend a hosting service that does? Looking for somewhere to put Gradle plugins and little libs that aren’t private but are too raw for the Plugin Portal or Maven Central. 

Perhaps something like:
```public fun Project.resolveProperty(name : String) : String? {
    return (extra[name]?: System.getenv(name)) as String? 
}```

Precisely doing `extra[""] ?:` Doesn't work since extra.get throws an exception, doesn't default to null when there's no such key found.

Also I'd optimally like to use this inside my settings file too, where I don't have access to `Project` afaik.

As a side note, where would you host such an extension function so that it's available throughout your entire project? For all modules?

adjust as appropriate.  The point was to create an extension function that encapsulates your specific requirements.  Settings will need a variation with some tweaks.  Typically these type of extension functions are in a composite `build-logic` project (successor to buildSrc).

Alright then I'm not missing some API and I'll just have to wrap what I wrote in my original comment in my own function.
Thanks for the help :pray:

Just use `project.findProperty`? That should automatically give you what you want. At least if the env variable does not have to be the exact same name, as there is a naming convention how to set a Gradle property.

But still can’t do that from inside settings.gradle.kts right, so I will have to do something special regardless. Also as far as the naming convention for the gradle property goes, I assume you’re talking about <https://docs.gradle.org/current/userguide/build_environment.html#sec:project_properties|this> just like in the <https://gradle-community.slack.com/archives/CAHSN3LDN/p1668371873646229?thread_ts=1668124853.248479&amp;cid=CAHSN3LDN|other thread> where Nuh suggested I add the `ORG_GRADLE_PROJECT` suffix right?

Yes, in settings script there is unfortunately no `findProperty`. And yes about the naming convention.

Or just use `val propertyName: String? by project` or `by settings` when applicable. Requires use of a naming convention (gradle property must be valid kotlin identifier then) and supports setting via env var in the same way as above.

In settings I opted to doing `providers.gradleProperty("KEY").getOrElse(System.getenv("KEY"))`.
I didn’t know this `settings` existed. If I did this `by settings` and it only exists in the environment variables (true for our CI) would it work? Or would I still need to fallback to null, and do System.getEnv() anyway?

If you follow the mentioned naming convention it will work

Of that I'm not sure. ORG_GRADLE_PROJECT suggests that no(

Hm, good point, but that is probably more a left-over from them being called "project properties" while they are now called "Gradle properties"

For a variant with provider factory you could use providers.gradleProperty(..).or(providers.environmentVariable(..))

As expected, `ORG_GRADLE_PROJECT_propertyName` works fine, also in settings script, I quickly tried

Good to know. I'm afk right now so couldn't check

Aha! So it will still work if I follow the naming conventions, and I can avoid doing System.getEnv()
So I can go from
`providers.gradleProperty("KEY").getOrElse(System.getenv("KEY"))`
to
`providers.gradleProperty("KEY").getOrElse(providers.environmentVariable("KEY").get()).`
Interesting!

For the `by settings` case, awesome to hear that it works, thanks for checking :raised_hands:
Is there a way I can do this more inline instead of having to assign it to a variable using `by`?
Just so that it doesn’t have to do something like this
```val x: String by settings
this.foo = x```

The point is, that it takes the name from the variable name

You shouldn't use provider.get when you don't need it. Just use provider.orElse to pass the fallback provider

And be aware that if you use `providers.gradleProperty` in a build script, you will *not* get the extra properties considered.

What is “extra properties” in this context?

Okay damn, quite a lot of things to consider in this one. On one hand I’d love there to be 1 option and not have too many things to choose from, but I also understand why there may be many reasons why there are all these options there in the first place.
Thanks a ton for walking me through this, I really do appreciate it! I think I got the right information now do what I need to do :thank_you:

That pegasus plugin tries to relativize a file path using another file path, but they are on different drives. This is probably a bug in that plugin, at least that it does not give a more meaningful error message.

Thank you, you are right. I just saw this bug on the official website of the project I was trying to compile.

While I don't know what `buildDirectory` is and whether it is the right approach to unpack all files when you actually just want the json file, it could be done with an artifact transform actually, but yes, it should also work fine with a copy task like you showed. I don't know how that should influence the compilation of your code though, especially without the concrete error message and the actual build scripts or at least an MCVE.

`buildDirectory` is a custom directory that should exist already or it will be made.

I seem to be getting closer to a solution but I will have a look at Artifact transform.

With the custom configuration it’s not really an error message. The classes in Project B just can’t load any classes from Project A if I use the custom configuration like the dependency is never downloaded.

Thanks for the answer though. I will see if I can find a solution with copy or artifact transform.

What has that to do with Amanda's post?
What is Vocareum?
If you get compilation errors, obviously your syntax is not correct. And if that is the case, it is not a Gradle problem and so the wrong place to ask.
But we can hardly tell you even whether it is the right place to ask as you neither provided your stuff, not even the error message. How should we help interpret an error message you do not provide? ;-)

Same goes for the `test-report-aggregation` plugin

I created an issue at <https://github.com/gradle/gradle/issues/22744>

Maybe using `onlyIf` checking whether `B` is in the task graph. But I'm not sure whether this will be configuration cache safe

I am not using configuration cache right now (I had some issues with it). So I will give it a try. Thanks.

By the way, is there any other way how to execute a task after some other task regardless its result besides `finalizedBy` ?

In this specific case, wouldn't a `B.dependsOn(A)` and `A.mustRunAfter(test)` be enough?

Hm, also a good point in case `A` can be run before `B`

`mustRunAfter` doesn't force `A` to run if `test` fails. And I need `A` to always execute its action regardless `test`'s result.

Yeah, right, build would fail after `test` failed. You would then additionally use `--continue`

I do not want `A` to fail. It does some stuff with junit xml reports. And I do not want the entire build to continue if test fails.

Sorry, meant after "`test`" failed of course

Will look at it tomorrow. Thanks for now.

That did the trick! Thank <@UDC9Q9RD0> and <@URQ797WRW>.

that cryptic error message is from Groovy closuress (imo, it’s a not-so-subtle hint to use Kotlin for build scripts).
For your specific situation - JVM toolchains were introduced in Gradle 6.7, you are running Gradle 6.5.

Ahhh... our repo is infested with many different versions of Gradle wrapper, but it is very difficult updating gradle wrapper because it won't upgrade until all your other gradle files are sane...

Also, using Kotlin for build scripts is in no way possible for us. Our Big Ball Of Mud is too big to accommodate such a drastic change.

fair enough.  fyi, it can be done incrementally, one script at t time.

You don't understand how messed up our environment is... While I would prefer to switch to Kotlin, doing this one script at a time would make the problem worse...

I highly doubt it. Why would you want to do that? Maybe there's a better solution to your actual use-case.

2 reasons:
1. it hopefully saves a tiny bit of build time 
2. I've had issue with out-of-date builds when using composite builds + accessors

This <https://github.com/gradle/gradle/issues/22095|issue> is for project accessors but I'm pretty sure I've seen it with version catalog accessors too

the accessors are cached (compiled) once built, reused for subsequent builds.

I recently had to move a project to a NAS device. My scripts are getting the error below:
`Could not create service of type ChecksumService using BuildSessionScopeServices.createChecksumService().`

From what I can tell, the error is due to permissions issues. Is it possible to run scripts on a networked drive? If so what should my permissions be to do so?

is it perhaps this:
&gt; ```The consumer was configured to find a runtime of a library compatible with Java 11```
combined with the Java 8 toolchain?

`access-ai` is looking for libraries from those projects compatible with Java 11.  You’ve stated those projects use Java 8.

Are you saying that Java 11 is not backwards compatible with Java 8?

`access-ai` uses
```java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(11)
    }
}```

The project it’s consuming don’t appear to be providing metadata on their Java compatibility:
&gt; ```None of the consumable configurations have attributes.```
…not sure what causes that.  May be worth reviewing how those ones are built, is everyone using the same Gradle version, etc.

&gt; …not sure what causes that.
Thank you for being honest

&gt; is everyone using the same Gradle version?
:laughing: :sweat_smile: :rolling_on_the_floor_laughing: :joy:

I think our project has more different versions of Gradle wrapper than there are stars in the universe...

understood.  that could contribute to the issue as newer Gradle version produce/expect metadata that may not be generated with older versions.  Would need to dig to understand how to configure this.

Yes, in my experience, the various outdated versions of the Gradle wrapper are a plague on our project...

I have been down this road before, and was ultimately defeated in trying to resolve it... the gradle wrapper update mechanism is effectively broken in terms of developer experience... it is very hostile to use.

This is perhaps why we have so many version of Gradle wrapper, because no-one likes the barrier to keeping things up-to-date

`./gradlew wrapper` (twice) will do the upgrade.

I don't believe you, but I will try it... :face_with_raised_eyebrow:

Do you really mean `./gradlew wrapper` ?

Usually, I use `gradle wrapper` which is always the latest version of Gradle...

<https://docs.gradle.org/current/userguide/gradle_wrapper.html#sec:upgrading_wrapper|Docs>.  At the root of a project you can do `./gradlew wrapper --gradle-version 7.5.1`.

```eric.kolotyluk@Y2RCV7009N access-ai % ./gradlew wrapper```
fails twice

```eric.kolotyluk@Y2RCV7009N access-ai % ./gradlew wrapper --gradle-version 7.5.1

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/eric.kolotyluk/git/autonomous-iam/access/access-ai/build.gradle' line: 266

* What went wrong:
A problem occurred evaluating root project 'access-ai'.
&gt; Could not resolve all files for configuration ':runtimeClasspath'.
   &gt; Could not resolve project :observability:bundle.
     Required by:
         project :
         project : &gt; project :common-utils
      &gt; No matching configuration of project :observability:bundle was found. The consumer was configured to find a runtime of a library compatible with Java 11, packaged as a jar, and its dependencies declared externally but:
          - None of the consumable configurations have attributes.

* 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>

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See <https://docs.gradle.org/6.8.3/userguide/command_line_interface.html#sec:command_line_warnings>

BUILD FAILED in 502ms```
This is precisely why Gradle wrapper is such a disaster... It sanity checks the gradle files, and refuses the upgrade until it is happy

ah.  it isn’t sanity checking them, it’s loading the configuration model.  Gradle work (lifecycle) is separated into configuration-time and execution-time - you have some janky code that is doing expensive actions at configuration-time.

that would be an error regardless of running the wrapper (or any Gradle task).

one workaround for that code is to move the setting of attributes into a `doFirst` block.

```jar {
    archiveFileName = "${project.name}.jar"
    doFirst {
        manifest {
            attributes('Main-Class': 'com.forgerock.access.access.Main',
                    'Class-Path': configurations.runtimeClasspath.files.collect { "libs/$it.name" }.join(' ') // line 266
            )
        }
    }
}```

I agree we probably have "some janky code" -- we probably have lots of "some janky code"

```jar {
    archiveFileName = "${project.name}.jar"
    doFirst {
        manifest {
            attributes('Main-Class': 'com.forgerock.access.access.Main',
                       'Class-Path': configurations.runtimeClasspath.files.collect { "libs/$it.name" }.join(' ')
            )
        }
    }
}```
Same error

that should now allow you to run the wrapper.  It still still fail when executing the `jar` task, as all we did is move the problem from configuration time to execution time.

```eric.kolotyluk@Y2RCV7009N access-ai % ./gradlew --version

------------------------------------------------------------
Gradle 7.5.1
------------------------------------------------------------```
:partying_face:

After cleaning up the `build.gradle` errors because of version 7.5.1, I am left with

```eric.kolotyluk@Y2RCV7009N access-ai % ./gradlew clean build

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':copyLibs'.
&gt; Could not resolve all task dependencies for configuration ':runtimeClasspath'.
   &gt; Could not resolve project :observability:bundle.
     Required by:
         project :
         project : &gt; project :common-utils
      &gt; No matching configuration of project :observability:bundle was found. The consumer was configured to find a runtime of a library compatible with Java 11, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally but:
          - None of the consumable configurations have attributes.

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

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

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.5.1/userguide/command_line_interface.html#sec:command_line_warnings>```

how is the dependency on `common-utils` defined in build.gradle?

```    //JAS libraries
    implementation project(":service-commons")
    implementation project(":service-config")
    implementation project(":modules-api")
    implementation project(":common-utils")
    implementation project(":encrypt-utils")
    implementation project(":gcp-utils")
    implementation project(":jas-rest-client-java")
    implementation project(":event-lib")```
```include ':observability:bundle'
project(':observability').projectDir = file('../observability')
project(':observability:bundle').projectDir = file('../observability/bundle')

include ':service-commons'
project(":service-commons").projectDir = file("../../autonomous-commons/service-commons")

include ':service-config'
project(":service-config").projectDir = file("../../autonomous-commons/service-config")

include ':modules-api'
project(":modules-api").projectDir = file("../../modules/api")

include 'common-utils'
project(":common-utils").projectDir = file("../../utils")

include 'gcp-utils'
project(":gcp-utils").projectDir = file("../../autonomous-commons/gcp-utils")

include 'encrypt-utils'
project(":encrypt-utils").projectDir = file("../../jas/common-utils")

include ':jas-rest-client-java'
project(":jas-rest-client-java").projectDir = file("../../autonomous-commons/jas-rest-client-java")

include 'event-lib'
project(":event-lib").projectDir = file("../../autonomous-commons/event-lib")```

thx.  that include the sub-projects - in the main build.gradle is it doing something like `implementation(project(":observability:bundle"))?`

Yes, `implementation project(':observability:bundle')`

```include ':observability:bundle'
project(':observability').projectDir = file('../observability')
project(':observability:bundle').projectDir = file('../observability/bundle')```

and is `:observability:bundle` creating a jar library?

Is it a naming problem with the jar file?

don’t think so, that’s all handled internally.

does this work: `./gradlew :observability:bundle:clean :observability:bundle:jar`

```eric.kolotyluk@Y2RCV7009N access-ai % ./gradlew :observability:bundle:clean :observability:bundle:jar

FAILURE: Build failed with an exception.

* What went wrong:
Task 'clean' not found in project ':observability:bundle'.

* Try:
&gt; Run gradlew tasks to get a list of available tasks.
&gt; Run with --stacktrace option to get the stack trace.
&gt; Run with --info or --debug option to get more log output.
&gt; Run with --scan to get full insights.

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

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.5.1/userguide/command_line_interface.html#sec:command_line_warnings>

BUILD FAILED in 423ms```

thats odd.  Typically for a jar-producing project it would have the standard lifecycle tasks (`clean` etc).  what plugins does that project apply?

I removed the version declarations, so now I get

suspect that the bundle project is missing configuration to expose its artifacts for consumption.

I seem to recall the snapshot version caused some problems in the past, but it did not help this time...

that project should have the below specified to create a JAR that other projects can consume:
```plugins {
    id 'java-library'
}```


is that for `:observability:bundle`?  Suspect it’s not as the `clean` task was missing there.

&gt; As indicated above, this plugin adds basic building blocks for working with JVM projects. Its feature set has been superseded by other plugins, offering more features based on your project type. Instead of applying it directly to your project, you should look into the `java-library` or `application` plugins or one of the supported alternative JVM language.
^^^ for the `java` <https://docs.gradle.org/current/userguide/java_plugin.html|plugin>.  Should be using `java-library` to create a JAR.

```eric.kolotyluk@Y2RCV7009N access-ai % ./gradlew clean build                                          

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':copyLibs'.
&gt; Could not resolve all task dependencies for configuration ':runtimeClasspath'.
   &gt; Could not resolve project :observability:bundle.
     Required by:
         project :
         project : &gt; project :common-utils
      &gt; No matching configuration of project :observability:bundle was found. The consumer was configured to find a runtime of a library compatible with Java 11, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally but:
          - None of the consumable configurations have attributes.

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

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

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.5.1/userguide/command_line_interface.html#sec:command_line_warnings>

BUILD FAILED in 449ms```

Is this working now?
```./gradlew :observability:bundle:clean :observability:bundle:jar```

build.gradle

```eric.kolotyluk@Y2RCV7009N access-ai % ./gradlew :observability:bundle:clean :observability:bundle:jar                                                               

FAILURE: Build failed with an exception.

* What went wrong:
Task 'clean' not found in project ':observability:bundle'.

* Try:
&gt; Run gradlew tasks to get a list of available tasks.
&gt; Run with --stacktrace option to get the stack trace.
&gt; Run with --info or --debug option to get more log output.
&gt; Run with --scan to get full insights.

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

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.5.1/userguide/command_line_interface.html#sec:command_line_warnings>

BUILD FAILED in 425ms```

`id 'java'` is redundant, included in application.

ok, let’s fix this issue first - the bundle project should apply `java-library` plugin, which provided a clean task.

is this working now? `./gradlew :observability:bundle:clean`

```eric.kolotyluk@Y2RCV7009N access-ai % ./gradlew :observability:bundle:clean

FAILURE: Build failed with an exception.

* What went wrong:
Task 'clean' not found in project ':observability:bundle'.

* Try:
&gt; Run gradlew tasks to get a list of available tasks.
&gt; Run with --stacktrace option to get the stack trace.
&gt; Run with --info or --debug option to get more log output.
&gt; Run with --scan to get full insights.

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

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.5.1/userguide/command_line_interface.html#sec:command_line_warnings>

BUILD FAILED in 430ms```

How about `./gradlew :observability:bundle:jar`?

```eric.kolotyluk@Y2RCV7009N access-ai % ./gradlew :observability:bundle:jar

FAILURE: Build failed with an exception.

* What went wrong:
Task 'jar' not found in project ':observability:bundle'.

* Try:
&gt; Run gradlew tasks to get a list of available tasks.
&gt; Run with --stacktrace option to get the stack trace.
&gt; Run with --info or --debug option to get more log output.
&gt; Run with --scan to get full insights.

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

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.5.1/userguide/command_line_interface.html#sec:command_line_warnings>

BUILD FAILED in 384ms```

wowsers.  not what is expected.  Grab this output:
```./gradlew :observability:bundle:tasks --all```

```eric.kolotyluk@Y2RCV7009N access-ai % ./gradlew :observability:bundle:tasks --all

&gt; Task :observability:bundle:tasks

------------------------------------------------------------
Tasks runnable from project ':observability:bundle'
------------------------------------------------------------

Help tasks
----------
buildEnvironment - Displays all buildscript dependencies declared in project ':observability:bundle'.
dependencies - Displays all dependencies declared in project ':observability:bundle'.
dependencyInsight - Displays the insight into a specific dependency in project ':observability:bundle'.
help - Displays a help message.
javaToolchains - Displays the detected java toolchains.
outgoingVariants - Displays the outgoing variants of project ':observability:bundle'.
projects - Displays the sub-projects of project ':observability:bundle'.
properties - Displays the properties of project ':observability:bundle'.
resolvableConfigurations - Displays the configurations that can be resolved in project ':observability:bundle'.
tasks - Displays the tasks runnable from project ':observability:bundle'.

Other tasks
-----------
components - Displays the components produced by project ':observability:bundle'. [deprecated]
dependentComponents - Displays the dependent components of components in project ':observability:bundle'. [deprecated]
model - Displays the configuration model of project ':observability:bundle'. [deprecated]

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.5.1/userguide/command_line_interface.html#sec:command_line_warnings>

BUILD SUCCESSFUL in 404ms
1 actionable task: 1 executed```

that’s…. an empty project.  Check that the include paths are correct.

This include:
```include ':observability:bundle'
project(':observability').projectDir = file('../observability')
project(':observability:bundle').projectDir = file('../observability/bundle')```
…is that the correct pathing?  Is there a build.gradle in `../observability/bundle`?

all the other includes, including this commented out one, go up two directory levels:
```//include ':observability:bundle'
//project(':observability').projectDir = file('../../observability')
//project(':observability:bundle').projectDir = file('../../observability/bundle')```

OMG... I keep making the same copy/paste mistakes over and over again...

The way we link projects together is INSANE

yes.  The idiomatic approach is to have those as directories underneath the root project and not have to set projectDir.

I keep stressing to my boss we need a complete overhaul of how we are using Gradle

```eric.kolotyluk@Y2RCV7009N access-ai % ./gradlew clean build

&gt; Task :common-utils:compileJava
Note: /Users/eric.kolotyluk/git/autonomous-iam/utils/src/main/java/com/forgerock/autoid/utils/Mapper.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

&gt; Task :event-lib:compileJava
Note: /Users/eric.kolotyluk/git/autonomous-iam/autonomous-commons/event-lib/src/main/java/com/forgerock/autoid/event/pubsub/PubSubHelper.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

&gt; Task :service-commons:jandex
Index has been written to /Users/eric.kolotyluk/git/autonomous-iam/autonomous-commons/service-commons/build/resources/main/META-INF/jandex.idx

&gt; Task :service-commons:jar
Execution optimizations have been disabled for task ':service-commons:jar' to ensure correctness due to the following reasons:
  - Gradle detected a problem with the following location: '/Users/eric.kolotyluk/git/autonomous-iam/autonomous-commons/service-commons/build/resources/main'. Reason: Task ':service-commons:jar' uses this output of task ':service-commons:jandex' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to <https://docs.gradle.org/7.5.1/userguide/validation_problems.html#implicit_dependency> for more details about this problem.

&gt; Task :compileScala
'jvm-1.11' is not a valid choice for '-target'
bad option: '-target:jvm-1.11'

&gt; Task :compileScala FAILED

FAILURE: Build completed with 2 failures.

1: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':compileScala'.
&gt; Compilation failed

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

2: Task failed with an exception.
-----------
* What went wrong:
java.lang.StackOverflowError (no error message)

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

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

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.5.1/userguide/command_line_interface.html#sec:command_line_warnings>

Execution optimizations have been disabled for 1 invalid unit(s) of work during this build to ensure correctness.
Please consult deprecation warnings for more details.

BUILD FAILED in 24s
42 actionable tasks: 34 executed, 8 up-to-date```
STACK OVERFLOW???

```&gt; Task :compileScala
'jvm-1.11' is not a valid choice for '-target'
bad option: '-target:jvm-1.11'```

You would think I could find that in our file system, and you would be wrong...

its either specifically set - `1.11` - or derived (incorrectly) from the Java 11 version that is set, which may indicate an older Scala plugin version.

```    implementation "com.fasterxml.jackson.module:jackson-module-scala_2.12:${jacksonVersion}"```
???

not seeing how that is related to a scala compile task?

I remember fighting this battle before, but cannot remember how I found it

it’s bundled with Gradle - is this now Gradle 7.5.1?

that’s likely what broke it, as several components stopped accepting the `1.x` qualified Java versions for anything after 1.8 (iirc).  Anyhow, you’ll need to track down where the Scala JVM version is set and correct it.

Perhaps <https://github.com/gradle/gradle/pull/18347|this> or <https://github.com/gradle/gradle/issues/19456|this> are relevant.

This is really insane... I cannot figure out who is setting 'jvm-1.11' is not a valid choice for '-target'

looks like the introduction of toolchains trips this up.  From issue, the options appear to be:
```update the dependency to 2.10.7, or
remove the toolchain definition and go back to the old block```

Is there any way to explicitly tell the scala plugin what to do with the jvm target?

Our use of jackson with scala makes this so much harder...

I now believe that scala in incompatible with Gradle...

Sorry, just getting really frustrated now...

Apparently
```scala {
    compileScala.targetCompatibility = 1.8
    ScalaCompileOptions.metaClass.useAnt = false
}```
has no effect

This has no effect either
```tasks.withType(ScalaCompile) {
    scalaCompileOptions.with {
        sourceCompatibility = "1.8"
        targetCompatibility = '1.8'
    }
}```

I am beginning to think the scala plugin I am using is broken...

StackOverflow has many issues related to this, and I have been trying all the solutions

perhaps check the Scala version in the affected project (from that issue s/b 2.10.7+).

`implementation 'org.scala-lang:scala-library:2.12.1'`

I have set everything to 2.10.7, and that does not help

perhaps create a small, minimal project to reproduce this.

Something like
```apply plugin: 'scala'

repositories {
    mavenCentral()
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(8)
    }
}

dependencies {
    implementation 'org.scala-lang:scala-library:2.10.4'
}```

when I use java 8, it breaks all kinds of other things...

adjust as needed.  point is to have a separate, reproducible project that you can explore options to resolve this in.

Apparently, there is no way to specify the version of the scala plugin to use. I believe the version I am using is broken

These kinds of scala plugin problems have been reported for over 3 years

```java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(8)
    }
}```
results in
```eric.kolotyluk@Y2RCV7009N access-ai % ./gradlew clean build

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':copyLibs'.
&gt; Could not resolve all task dependencies for configuration ':runtimeClasspath'.
   &gt; Could not resolve project :service-commons.
     Required by:
         project :
      &gt; No matching variant of project :service-commons was found. The consumer was configured to find a runtime of a library compatible with Java 8, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally but:
          - Variant 'apiElements' capability com.forgerock.autoid:service-commons:1.0-SNAPSHOT declares a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares an API of a component compatible with Java 11 and the consumer needed a runtime of a component compatible with Java 8
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
          - Variant 'mainSourceElements' capability com.forgerock.autoid:service-commons:1.0-SNAPSHOT declares a component, and its dependencies declared externally:
              - Incompatible because this component declares a component of category 'verification' and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
                  - Doesn't say anything about its target Java version (required compatibility with Java 8)
                  - Doesn't say anything about its elements (required them packaged as a jar)
                  - Doesn't say anything about its usage (required a runtime)
          - Variant 'runtimeElements' capability com.forgerock.autoid:service-commons:1.0-SNAPSHOT declares a runtime of a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component compatible with Java 11 and the consumer needed a component compatible with Java 8
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
          - Variant 'testResultsElementsForTest' capability com.forgerock.autoid:service-commons:1.0-SNAPSHOT:
              - Incompatible because this component declares a component of category 'verification' and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything about how its dependencies are found (required its dependencies declared externally)
                  - Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
                  - Doesn't say anything about its target Java version (required compatibility with Java 8)
                  - Doesn't say anything about its elements (required them packaged as a jar)
                  - Doesn't say anything about its usage (required a runtime)

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

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

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.5.1/userguide/command_line_interface.html#sec:command_line_warnings>```

Yes.  Expected when other libs are compiled with Java 11.

Taking a lunch break for a while... I am super stressed out now...

As much as I hate SBT, it is the most reliable way to deal with Scala.

I have had success using Maven with Scala, but only on the back-end. Maven cannot build a Scala front-end, only SBT can.

I am still a Gradle newbie, but my impression is that the Gradle Scala plugin is not a serious product. There are too many complaints about the same things on StackOverflow and elsewhere, so whoever supports that code does not take it seriously.

Scala does not make life easy either, the lack of backwards compatibility forces everyone to use another layer of versions. At least SBT has some support for this.

<https://stackoverflow.com/questions/74467758/is-there-a-way-to-make-gradle-scala-plugin-work-correctly>

btw, for all those includes with different paths - often find it helpful to have a utility function handle those, including validation of the paths, etc such that the boilerplate is minimized.  One possible option below.  Another option is to scan directories to include their projects (if there is a conventional layout).
```public fun Settings.includeProject(path: String) {
    if (path.contains("/") || path.contains("\\")) {
        throw GradleException("Invalid project path; must use ':' as project path separator")
    }
    val projectPath = when {
        path.startsWith(":") -&gt; path
        else -&gt; ":$path"
    }
    include(projectPath)
    val projectDesc = findProject(projectPath)
    check(projectDesc != null) { "Unable to resolve project @ path '$projectPath'" }
    val projectDir = File("../../" + projectPath.drop(1).replace(":","/"))
    check(projectDir.exists()) { "Project directory does not exist: $projectDir"}
    projectDesc.projectDir = projectDir
}

/*

### Original
include ':observability:bundle'
project(':observability').projectDir = file('../observability')
project(':observability:bundle').projectDir = file('../observability/bundle')

Could become:

includeProject(":observability:bundle")
 */```

Another problem with Gradle is that most internet documentation is out-of-date because Gradle keeps changing the names of things but cannot tell you that at run time...

Yes, but the internet is full of examples still using it...

Many internet articles have no date attached, so you cannot know how current they are...

I guess there is no way for Gradle to emit a diagnostic: compile not supported, do you mean 'complileOnly'

Gradle did emit deprecation warnings for quite a few versions on this, before fully removing support.

That is not good enough. As I stated, there is abundant stale knowledge on the internet, and generally, Gradle has some of the poorest diagnostics I have ever seen in a tool.

Also, the page <https://docs.gradle.org/current/userguide/declaring_dependencies.html> is horrible... just a mish-mash of random thoughts.

Why is there no canonical list of examples?

As a rule, diagnostics should serve to guide people toward solutions and not simply make vague statements that lead to confusion.

Another part of the problem is that Gradle is evolving too quickly, and the diagnostics and documentation do not consider this.

`compile` was deprecated for _years_ before being removed.  At some point things move on.

&gt; The usage of the `compile` and `runtime` configurations in the Java ecosystem plugins has been discouraged since <https://docs.gradle.org/3.4/release-notes.html#the-java-library-plugin|Gradle 3.4>.

I think you are missing the point... the internet has much stale knowledge...

A useful diagnostic would be "Do you mean 'compileOnly'?"

Are you advocating that Gradle should have abstruse diagnostics?

On the page <https://docs.gradle.org/current/userguide/declaring_dependencies.html> the string `compileOnly` does not appear.

It had those diagnostic messages - for many years.  Over time that baggage builds up, it cannot persist forever, becomes a drag on the code base.  Using Kotlin DSL for scripts provides completion, error highlighting, deprecation warnings, etc.

that page is a general overview of declaring dependencies.  `compileOnly` is a java-specific configuration, <https://docs.gradle.org/current/userguide/java_plugin.html|documented> accordingly.

The bottom like is, Gradle is the most frustrating tool I use on a daily basis. I am trying to suggest ways of improving it, but there is always some reason not to improve it.

<https://docs.gradle.org/current/userguide/java_plugin.html> is very helpful, thank you... I would never have known about this using regular methods such as google search

np.  it’s helpful to wade through the entirety of the Gradle docs for awareness of what is there.

and ignore the ancient StackOverflow posts :wink:

It would be helpful if the Gradle documentation were not so poorly written.

I actually find it generally useful for common cases.  I know you have some specific, non-idiomatic needs that make it a bit challenging.

We may have to hire you to overhaul our Gradle usage...

Once my boss agrees to the clean-up project, I will be searching for consultants to hire...

I think gradle documentation is excellent if you already know where to look and what you're looking for, but need to know how to do something. 

Discoverability is a big issue, though with enough experience you start to get a feel for where to look

Btw. `compileOnly` is not really an appropriate replacement. `compile` was more like `implementation` or `api`. `compileOnly` means it is only available at compile time, but not at runtime except if someone else provides is.

For upgrades it’s worth checking <https://docs.gradle.org/current/userguide/upgrading_version_7.html|the upgrade guide>, where is a list of changes. For removal of compile you can check <https://docs.gradle.org/current/userguide/upgrading_version_6.html#sec:configuration_removal|here>. I hope that helps a bit.

It was not about upgrading though <@U02DF9JDXJM>.
It is about following outdated tutorials or SO answers that contain things that are simply not present anymore as they finished the deprecation cylce like the "compile" configuration.

Increasingly, Google Search turns up garbage, especially out-of-date garbage...

Too bad they can't use some AI to filter the garbage better and return relevant information... but then they would lose ad revenue wouldn't they...

Filter by last year (or even 1 month) in Google.

Sure, just look at the `application` plugin code and do it the same. It adds a `JavaExec` task called  `run` that is wired properly to run the production code.

Thanks will check it out…. :slightly_smiling_face:

you shouldn't do that, as this is unsafe and will eventually break (with project isolation)

you should refer to <https://docs.gradle.org/current/userguide/cross_project_publications.html#sec:simple-sharing-artifacts-between-projects> for a safe solution

agreed that it is not ideal as this requires some ceremony...

long story short: if you need the output of a task from another project, then it should be declared as a proper "outgoing artifact".

If thats the way to go, I will have a look at it again. Seams overly complicated for somethings as simple as sharing project outputs.

It's not super complicated once you are used to it :slightly_smiling_face: Mindset shift.

there could be some conventional way to refer to another project task's as an input, for example, by having some implicit outgoing configuration for every task. That would work, but it would still be much more fragile than the recommended way. For example, it would break as soon as you rename the task, or, as soon as you want more tasks to contribute to that output.

Still got a lot of question marks.

At the producer side i have:
```task buildClient(type: Exec) {
    outputs.dir file('build')
    ....
}

configurations {
    webResource {
        canBeConsumed = true
        canBeResolved = false
    }
}

artifacts {
    webResource(buildClient.outputs.files.singleFile)
//   Documentation suggests this is needed but adding it results in a compile error missing function
//   {
//        buildBy(buildClient)
//   }
}```
Consumer:
```configurations {
    webResources {
        canBeConsumed = false
        canBeResolved = true
    }
}

dependencies {
    // If i get this correct this means, put the webResource from consumer-proj into the webResources configuration
    webResources(project(path: ':consumer-proj', configuration: 'webResource'))
}

sourceSets {
    main {
        resources  {
            srcDir(configurations.webResources.resolve())
        }
    }
}```
Runs but the resources are not there and `buildClient` is not run

so apparently using a configuration as `srcDir` triggers a `StackOverflowError`

so I managed to make this work by using an intermediate task. On the producer:

```plugins {
   id 'base'
}

configurations {
    webResources {
        canBeConsumed = true
        canBeResolved = false
    }
}

def generateSources = tasks.register("generateSources", GenerateSources) {
    outputDirectory = layout.buildDirectory.dir("generated-java")
}

configurations.webResources.outgoing.artifact(generateSources)

abstract class GenerateSources extends DefaultTask {
    @OutputDirectory
    abstract DirectoryProperty getOutputDirectory()

    @TaskAction
    void generate() {
       new File(outputDirectory.get().asFile, "Foo.java").text = "public class Foo {}"
    }
}```

then in the consumer:
```plugins {
    id 'java'
}

configurations {
    webResources {
        canBeConsumed = false
        canBeResolved = true
    }
}

dependencies {
    webResources project(path:':producer', configuration: 'webResources')
}

def copy = tasks.register("copy", Copy) {
    from configurations.webResources
    into layout.buildDirectory.dir("sources-java")
}

sourceSets {
   main {
       java.srcDir(copy)
   }
}```

I wished we could use `sourceSets.main.java.srcDir(configurations.webResources` directly, but this triggers the `StackOverflow`

Yeah, ran into the StackOverflow as well.

Seeing this, it feels a lot more complicated and less elegant than the initial sollution

But it is not unsafe and unsupported :-D

Btw. the compile error was due to `buildBy` vs. `builtBy`.

<@URQ797WRW> Agreed, I'm trying to fix it in the correct way. And indeed fixing the typo resolves the compile issue.

Got it working but still not sure if I like the solution.

On the producer side I now have:
```configurations {
    webResources {
        canBeConsumed = true
        canBeResolved = false
    }
}

artifacts {
    webResources(buildClient.outputs.files.singleFile) {
        builtBy(buildClient)
   }
}```
Adding all the outputs to the webResources artifact still seams clunky and only works because I know there is only one directory.  This is probably because the Exec task that is used to generate the resources has no nice OutputDir type `DirectoryProperty` . But overall this is not that bad.

Consumer:
```configurations {
    webResources {
        canBeConsumed = false
        canBeResolved = true
    }
}

dependencies {
    webResources project(path: ':producer', configuration: 'webResources')
}

def copy = tasks.register("copy", Copy) {
    from configurations.webResources
    into layout.buildDirectory.dir("webresources")
}

sourceSets {
    main {
        resources  {
            srcDir(copy)
            //srcDir(tasks.getByPath(":producer:buildClient").outputs)
        }
    }
}```
Sill don't really like the extra copy task. Upside I suppose is that the copy task allows me to place the artifacts in a sub dir if needed.

Should I submit a bug report about the stackoverflow if you do `srcDir(configurations.webResources)`?

Sounds to me like it should either be fixed or at least have some sanity check and fail in a more meaningful way.

I'm using a `resolutionStrategy` to use a specific version across a set of libraries (specifically the Jetpack compose libraries, because the Jetbrains compose for desktop brings in a different version than the one I want to use).

Recently, Google suggested to use the compose BOM; how could that be used with `resolutionStrategy` and `useVersion`?

Adding to that, it looks like top level functions are not recognized in scripts that are applied?
This fails to compile:
```fun RepositoryHandler.addRepos() {
  mavenCentral()
  google()
  // more
}

pluginManagement {
  repositories {
    // Unresolved reference: addRepos
    addRepos()
  }
}

dependencyResolutionManagement {
  repositories {
    addRepos()
  }
}```

the blocks that affect the script's build classpath need to be executed outside of the context of the whole script

The `pluginManagement` block is extracted and evaluated separately before the settings script itself is compiled, otherwise its content could not influence the plugins that you can apply to the settings script itself. Due to that you of course cannot reference anything outside that block. Same for `plugins` blocks or `buildscript` blocks.

But you can on the other hand inside the `pluginManagement` block configure other objects. So what I sometimes did is:
```// the plugin management block is evaluated first separately, do not change this to
// listOf(pluginManagement.repositories, dependencyResolutionManagement.repositories)
// instead that would change the semantics
pluginManagement {
   listOf(repositories, dependencyResolutionManagement.repositories).forEach { repositories -&gt;
      repositories.apply {
         mavenCentral()
         google()
      }
   }
}

dependencyResolutionManagement {
   repositoriesMode.set(FAIL_ON_PROJECT_REPOS)
}```

Nice! I didn't realize `pluginManagement{}` was the same as `buildscript{}` but it makes a lot of sense :+1:

It's probably not the same, but at least similar in that regard :smile:

yea, that's what I meant :slightly_smiling_face:

How does it work for scripts that are applied? If I do `apply(from = "other.gradle.kts")` in `settings.gradle.kts` ? Is Gradle smart enough to know that the script is applied in the context of settings and "extract" the `pluginManagement` block?

It shouldn't work, same as with plugins block and apply from

What do you mean be "shouldn't work"? I get the feeling that it somewhat works at the moment