Open Malandril opened 1 month ago
/cc @geoand (kotlin), @glefloch, @quarkusio/devtools
cc @aloubyansky @cdsap
3.14.4 released today should address the issue.
Let's keep this issue open as I only reverted the changes in 3.14/3.15 and we still need to fix the issue in main
as we want to keep the enhancement that introduced the regression long term.
I'm investigating the issue. I was able to reproduce the issue in a simple project without Quarkus: https://github.com/cdsap/JavaPlatformIssue In my reproducer repo, the eager resolution of the configuration is triggered by:
tasks.register("foo") {
project.configurations.getByName("x").resolve()
}
following the reproducer of this issue, the eager resolution points to:
collectConditionalDependencies(baseRuntimeConfig.getResolvedConfiguration().getResolvedArtifacts());
at the ConditionalDependenciesEnabled.
Hello @cdsap Do you have any news on this issue ? as with quarkus 3.16.0.CR1, it still happens as the commit b542785c9125a85d64e5ef75c95f6d198c896a7c is present.
Hi @Malandril. I created #44032 explaining the issue, as the current limitation of using the eager configurations when forcing resolution, and proposing an alternative configuration where we avoid the forced resolution for the inputs of the new task.
Well done! Thanks a lot
Describe the bug
Since #42875 a gradle build depending on a java-platform and with early task resolution will fail with
Expected behavior
When a project depends on
java-platform
adding awill make the build fail
Actual behavior
No response
How to Reproduce?
reproducer
Output of
uname -a
orver
No response
Output of
java -version
No response
Quarkus version or git rev
3.14.3
Build tool (ie. output of
mvnw --version
orgradlew --version
)gradle 8.9
Additional information
No response