My project works fine with the latest Spring Releases: Spring 5.2.5.RELEASE, Spring Boot 2.3.0.M4, Spring Cloud 2020-1.M1, Spring Data Neumann-RC1, Spring Security 5.3.1.RELEASE. And also with Gradle 6.3.

However, after upgrading Gradle to 6.4-rc-1 I get the attached console output and stacktrace. gradle-6.4-rc-1.txt

Comment From: jjohannes

@juergenzimmermann There are some changes in the internal setup of the exec tasks because there is some new API to set the main class (or main module). But it should not cause a problem like this. Do you do anything specific to configure the "main" class in your build script?

See also: https://docs.gradle.org/6.4-rc-1/userguide/upgrading_version_6.html#new_properties_may_shadow_variables_in_build_scripts

Comment From: juergenzimmermann

I attach my reduced build.gradle.kts and builsSrc\src\main\kotlin\Versions.kt which are working fine with Gradle 6.3. I appended .txt to both files so that GitHub allows me to upload them.

build.gradle.kts.txt Versions.kt.txt

Comment From: snicoll

@juergenzimmermann to help us and the Gradle team, can you please share a link to a small project that reproduces the problem? A zip or a link to a github repo will do. The only thing we can do is copy those two resources in an actual project and try to figure out what the missing piece is.

Comment From: juergenzimmermann

@snicoll @jjohannes A testcase is attached. gradle bootRun starts a Spring Boot server when using Gradle 6.3, but not with 6.4-rc-1. testcase20984.zip

Comment From: jjohannes

We broke the traditional convention mapping for JavaExec.main. This affects the MainClassConvention in the spring boot plugin leading to this regression.

Thanks again @juergenzimmermann for trying this early and discovering it.

Will be fixed in 6.4 RC2 - https://github.com/gradle/gradle/issues/12833

Comment From: snicoll

Thank you very much @jjohannes for the assistance!

Comment From: wilkinsona

I wondered if our integration tests would have caught this. I've just run BootRunIntegrationTests with the compatibility extension updated to cover Gradle 6.4-rc-1 and all 6 tests that rely on the main class name convention fail.

Comment From: jjohannes

We also have some tests in our pipeline that test basic functionality of widely used plugins against our latest changes. But that can not cover all cases of course.

Still, we should have caught this one, as we broke very basic functionality of the boot plugin. But our Spring boot test was, well, not really testing anything unfortunately. :( That is fixed now.

But for less obvious things, it would be great if you could run your tests for the Boot Gradle plugin against latest Gradle releases on a regular basis (ideally against nightlies). If it is feasible for you to set that up. Then you can report issues early. The Nebula folks are doing that and it has been really helpful several times already.

Comment From: wilkinsona

@jjohannes is there something that we could consume programmatically to determine when a new nightly is available and what its version is?

Comment From: jjohannes

@wilkinsona Yes we have an API for that. This will give you the latest nightly: https://services.gradle.org/versions/nightly

We use that in our own build here for example: https://github.com/gradle/gradle/blob/15a44197644f8ca57abab27336daef4179744dfb/buildSrc/subprojects/versioning/src/main/kotlin/org/gradle/gradlebuild/versioning/WrapperPlugin.kt