It works with minimized demo project, but it doesn't register tasks such as processAot with my actual project, I have to add gradle plugin id("org.springframework.boot.aot") and configure task dependencies. It's a large multi-project build with complex build logic, not easy to minimize it to reproducer, before doing that, may I ask how to debug or there is any limitation I missed?

Comment From: bclozel

I think this only gets applied where the Spring Boot plugin is applied. The SpringBootPlugin should only be applied where the actual application JAR is built (not the intermediate modules) so this might explain the behavior you are seeing.

Comment From: wilkinsona

It could also be due to the class loader hierarchy that Gradle creates. https://github.com/spring-projects/spring-boot/issues/42601 is an example of that.

Comment From: quaff

It's caused by java.lang.NoClassDefFoundError: org/graalvm/buildtools/gradle/NativeImagePlugin 1734074455303

Comment From: mhalbritter

I saw that problem in the past, too. With the same exception you screenshotted. There it was related to the Gradle classloader hierarchy.

Comment From: quaff

Thanks to #42601, it's fixed by adding org.graalvm.buildtools.native:org.graalvm.buildtools.native.gradle.plugin dependency to buildSrc, I think it's worthy to document it.

Comment From: mhalbritter

Not sure about that - Gradle has a bazillion ways of applying plugins and I'm not keen to document them all. The down- and upsides and caveats of each plugin application technique should be documented on Gradle side.

Comment From: wilkinsona

I agree with @mhalbritter. We have to draw the line on what we document somewhere, and I think a situation such as this is beyond that line. I think it should be documented in https://docs.gradle.org/current/userguide/custom_plugins.html#custom_plugins and/or https://docs.gradle.org/current/userguide/sharing_build_logic_between_subprojects.html where the context that's necessary to understand the problem and solution is already documented.

Comment From: quaff

How about adding a note:

NOTE: If the tasks are not configured automatically, make sure you are declaring Spring Boot plugin and GraalVM Native Image plugin in the same way, for example:
[source,kotlin,indent=0,subs="verbatim,attributes"]
----
plugins {
    java
    id("org.springframework.boot") // The plugin doesn't need version because it's dependency of buildSrc
    id("org.graalvm.buildtools.native").version("latest.release") // You should declare it as dependency of buildSrc too and remove version
}
----

Comment From: wilkinsona

I don't think we should do that. buildSrc in only one option and, as @mhalbritter already said, there are others. Without all the necessary context (that Gradle's docs largely already provide) a small snippet like the above is likely to hinder rather than help.

Comment From: quaff

From developer perspective, at least it helps some people.

small snippet like the above is likely to hinder rather than help.

We could document it's one possible circumstance just for reference.

Comment From: wilkinsona

@quaff thanks for your enthusiasm here but I think it's misdirected. Please open a Gradle issue. Gradle is best placed to document the relationship between the structure of build's projects and the class loader hierarchy, including the affects of using buildSrc and included builds.