This commit adapts d44e7c9 to transforms plugin repositories using the
correct root tag. Previously, they were transformed with the regular
<repository> tag, which is invalid.
Closes gh-42687
When spring-boot-gradle-plugin is using GradleRunner, it needs to be
configured with a custom plugin classpath to account for the fact
that our Gradle plugin is on the classpath of the system classloader
but some of the other plugins would only be available on a
Gradle-created classloader. This imbalance cause class loading
problems as code in spring-boot-gradle-plugin can't see types at
runtime that are only available on the Gradle-created classloader.
To overcome this, we need to configure the GradleRunner with a custom
plugin classpath that contains both spring-boot-gradle-plugin and all
of the other plugins that are used in its various integration tests.
Previously, this was done in GradleBuild that's used by both
spring-boot-gradle-plugin and spring-boot-image-tests. This caused
a problem as spring-boot-image-tests does not have the
above-described problem and trying to correct it did not work leaving
tests that use spring-boot-gradle-plugin unable to see other plugins
such that the native image plugin.
This commit reworks the customization of the plugin classpath so that
it's only done in spring-boot-gradle-plugin's integration tests.
Closes gh-42338
This commit makes sure that integration tests for the Maven Plugin have
access to the current "spring-boot-starter-parent" pom and its
hierarchy as new integration tests rely on that.
Closes gh-42000
Previously, if a classifier was set and build-image was executed from
the command-line, the build will fail as the plugin was unable to find
the original jar. This is because it relies on the attached artifacts
of the project, and those are not set when package has run as part of
a forked lifecycle.
This commit makes sure that the backup file is found by convention
first, the same way it is done for the target file.
Closes gh-26721
This commit updates the Maven Plugin to tolerate projects that are using
the module path on the JVM and targeting native images with AOT.
Previously, the plugin compiled AOT sources directly to target/classes
and the presence of a module-info there is enough to trigger a
compilation on the module path.
With this change we now compile in a separate directory that contains
the generated AOT classes (typically CGLIB proxies). These are copied to
target/classes once compilation completes already.
The integration test also uses our parent, rather than relying on what
Maven provides. That's because older Maven versions provide a default
compiler plugin version that did not handle the module path correctly.
Closes gh-33383
Andy Wilkinson
Phillip Webb
Moritz Halbritter
Stéphane Nicoll
Andreas Höhmann
Tran Ngoc Nhan
YiXuan Ding
Yanming Zhou
arefbehboudi
mushroom528
Johnny Lim
Scott Frederick
Christoph Dreis
rajin