Spring-boot: "gradle bootRun" fails after upgrading to Gradle 6.4-rc-1

[juergenzimmermann]

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

[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

[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

[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.

[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

[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

[snicoll]

Thank you very much @jjohannes for the assistance!

[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.

[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.

[wilkinsona]

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

[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