-
Notifications
You must be signed in to change notification settings - Fork 41.1k
Spring boot plugin issue using gradle cache #39635
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@alexisgayte As was requested previously, please provide us with a complete minimal sample project that demonstrates the problem so we can run it ourselves. |
I have given the steps to reproduce it, doesn't seem to be consistent thought. but to be clear I have no idea how the plugin ended up calling : But the fact that the plugin uses a nonauthrized method during the execution time is de facto an issue and the issue. the issue seems to be linked to some tasks already cached thought. EDIT : from the plugin code
here is the full stack trace if that can help:
|
Interestingly, |
A task must not use any Project objects at execution time. This includes calling Task.getProject() while the task is running. See https://docs.gradle.org/7.0/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution Fix spring-projectsGH-39635
A task must not use any Project objects at execution time. This includes calling Task.getProject() while the task is running. See https://docs.gradle.org/7.0/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution Fix spring-projectsGH-39635
Closing in favor of #39644. |
Unfortunately, I was too quick to close this in favor of #39644 as I cannot reproduce the problem. That means there's no way of knowing if the PR will fix it. With a basic app generated from start.spring.io, running
Running the same build again then successfully reuses the configuration cache:
@alexisgayte we're back to needing a minimal sample to be able to make any progress here. Please start with a basic Gradle project generated on start.spring.io, make any amendments to it that are necessary to reproduce the problem and then share the project with us. |
I know, I spent some time already to try to reproduce it locally, and I couldn't. I tried to tweak https://github.com/spring-guides/gs-spring-boot. My guess is that somehow the gradle cache clean or don't populate bootJar.getManifest().getAttributes().get("Start-Class"). And the hack describe here failed :
It happens on a kubernetes env during a build process. this build runs without test "-x check" in theory it should fail with only one build before but it could have some cache: It is linked to the fact we use publish and attach the tasks to the artifact :
The best way probably to reproduce this issue, now that I understand a bit better what happen would be to create a task that call directly "resolveMainClassName.get().readMainClassName()". |
The information about how you're configuring publishing was one missing piece in the puzzle. I can reproduce the failure, or at least one similar to it, with this
The dependency management plugin doesn't support the configuration cache. It can be removed and replaced with Gradle's platform support:
With this configuration, not only are the pom-related problems caused by the dependency management plugin resolved, but the problem with
Are you using the dependency management plugin? If you're not, I'm not sure that we're really much closer to understanding the problem. |
No, I am using the BOM_COORDINATES. |
I could reproduce it locally,
Notice the generatePomFileForBootJavaPublication that happen just before the publish. |
I can see that you must have the Please share your project where you've been able to reproduce the problem. |
it seems that the issue is due to the use of a plugin to populate the publishing.
With my.plugin.MavenPublish being :
That somehow pushes the generatePomFileForBootJavaPublication task after, I believe this behaviour break the order Task :build |
Unfortunately, I still can't reproduce this in the way that you have described. Moving the publishing configuration into a separate plugin does not affect the ordering. I have also tried manually adding a depends on relationship: tasks.named('generatePomFileForBootJavaPublication') {
dependsOn tasks.named('build')
} This does change the ordering but does not reproduce the problem. Your latest example does not use the Rather than providing small and varying snippets of your build configuration, can you please provide a complete example so that we can unzip it, run a single command, and reproduce the problem? |
Yes sure, you are right the order is not the issue. Can you give me your project? I will try to reproduce it. |
Given that you have a project that reproduces the problem and I do not, I don't think mine's going to help. Please share a minimal version of yours. |
no worries, unfortunately my project is not shareable. For anyone that face this issue, as initially suggested monkey patch ResolveMainClassName works for me. side note "org.springframework.boot:spring-boot-loader-tools:3.x.x" would need to be imported for monkey patching it. |
This will hopefully be addressed by #40463. |
Thanks for your time and effort on this issue. Retrying some senaries :
TLDR: Bug fixed but new bug with gradle 8.7 probably not linked to it. Edit bug already referenced and ??fixed?? : #40911 |
#39326
Running Spring boot plugin with gradle 8.5 generate :
The issue is here :
https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/main/java/org/springframework/boot/gradle/plugin/ResolveMainClassName.java#L152-L161
We cannot call getProject().getProjectDir().toPath() at execution time
My understanding is that needs to be moved at the constructor level, here :
https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/main/java/org/springframework/boot/gradle/plugin/ResolveMainClassName.java#L67
The text was updated successfully, but these errors were encountered: