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
This commit clarifies how we intend the spring-boot:repackage goal to
be used. As it operates on the source jar (or war) that must be
effectively up-to-date to produce an accurate result, the package phase
must have run.
Contrary to build-image that was designed to be used on the command-line
by forking a package lifecycle first, repackage does not do that. This
commit also clarifies that by providing a more focused error message.
Closes gh-22317
This commit improves the configuration metadata annotation processor to
detect a default enum value. The algorithm is best-effort, similarly to
what it already does for well known prefixes (period, duration, etc).
Based on an expression and an identifier, the default value is inferred
if the expression matches the declaration of the property type.
See gh-7562
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
An `imagePlatform` option for the Maven and Gradle image-building
goal/task can be used to specify the os/architecture of any
builder, run, and buildpack images that are pulled during image
building.
Closes gh-40944
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
The use of method references requires the referenced method to be
present even if it isn't called. This made it impossible for Gradle
to remove the deprecated methods as it would break our plugin.
By switching the lambdas, the methods only have to be present when
they're called which will only happen with Gradle 8.2 and earlier.
Closes gh-41599
Andy Wilkinson
Moritz Halbritter
Stéphane Nicoll
mushroom528
Phillip Webb
martinfrancois
Johnny Lim
Scott Frederick
Christoph Dreis
rajin
John Blum
Eddú Meléndez