The warnings will be addressed by gh-20759. CreateBootStartScripts
must be excluded from the classes that are validated by the
ValidatePlugins task. It is invalid, but only for Gradle 6.4. gh-20759
will cause it to only be used with Gradle 6.3 and earlier.
See gh-21329
This commit changes the default builder image from
`cloudfoundry/cnb:bionic-platform-api-0.2` to
`gcr.io/paketo-buildpacks/builder:base-platform-api-0.3`. It also
uses a `paketo-buildpacks/builder` image instead of a
`cloudfoundry/cnb` image to test compatibility with lifecycle v2
and uses paketo naming instead of cloudfoundry when mocking builder
interactions.
Some adjustments to lifecycle phases were also made to align more
closely with the pack CLI.
Fixes gh-21066
Previously, the developmentOnly configuration, typically used for
Devtools, had to be declared manually. The BootJar and BootWar tasks
then had a property, excludeDevtools, that could be used to control
whether or not Devtools would be excluded from the executable archive.
This commit updates the reaction to the Java plugin being applied to
automatically create the developmentOnly configuration. The classpaths
of bootJar and bootWar are then configured not to include the contents
of the developmentOnly configuration. As a result of this, the
excludeDevtools property is no longer needed and has been deprecated.
Its default has also been changed from true to false to make it easy
to opt in to Devtools, when configured as a development-only
dependency, being included in executable jars and wars by adding
developmentOnly to the classpath of the archive task.
Closes gh-16599
This commit removes changes the timestamp used when writing the
classpath and layers index files in the Gradle plugin to be the
current timestamp unless `preserveFileTimestamps=true`. It also
polishes some duplication in the handling of entry attributes
when creating the fat archive and adds a test to verify that
the Gradle plugin uses the same fixed timestamp constant as
Gradle uses internally.
See gh-21005
This commit ensures that file permissions are set on entries that the
Gradle plugin adds to an archive. It also reverts the constant date
and time used for added entries to a previous value to ensure a time
zone offset is not applied.
See gh-20927
Update the Gralde plugin so that layered jars now use the regular "flat"
format. The layers.idx file now describes which layer each file should
be placed.
See gh-20813
Co-authored-by: Phillip Webb <pwebb@pivotal.io>
Create a dedicated layer that is used to hold the launcher support
classes. The layer sits between `dependencies` and
`snapshot-dependencies` so that the layer is sensible for both
SNAPSHOT and RELEASE versions of Spring Boot
Closes gh-20529
Simplify layer customization logic for both Maven and Gradle and
refactor some internals of the Gradle plugin.
Both Maven and Gradle now use a simpler customization format that
consists of `application`, `dependencies` and `layer order` sections.
The `application`, `dependencies` configurations support one or more
`into` blocks that are used to select content for a specific layer.
Closes gh-20526
This commit adds support for Cloud Native Buildpacks builder platform
API 0.3, which is the latest platform API available currently. Support
for platform API 0.1 has been removed, adopting the policy of the pack
CLI to support the current platform API version and one version prior.
Fixes gh-20757
CNB builder images are now being tagged in a manner that indicates
the version of the platform API implemented. This allows Spring Boot
to default to a builder tag that guarantees API compatibility while
allowing for updates to bundled buildpacks.
Fixes gh-20171
This commit adds support for setting the image name and builder
parameters of the Gradle bootBuildImage task using command-line
options as an alternative to DSL configuration.
See gh-20520
This commit adds configuration to the Spring Boot Gradle plugin that
allows the names and contents of layers to be customized in the build
configuration.
Fixes gh-20296
With this commit, the Maven `spring-boot:build-image` goal and the
Gradle `bootBuildImage` task will configure the OpenJDK buildpack
to use the same JRE version as the project's target version,
provided the buildpack Java version is not explicitly set in the
build configuration.
Fixes gh-20172
This commit adds a `createdBy` structure to the metadata of the ephemeral
builder container image that identifies Spring Boot as the creator of the
image, along with the Spring Boot version.
See gh-20126
This commit upgrades the default CNB builder image from
cloudfoundry/cnb:0.0.43-bionic to cloudfoundry/cnb:0.0.53-bionic.
It also adds integration tests for the Maven and Gradle plugins
to verify both versions are supported.
We build with Java 8, 11, and 13 without specifying target
compatibility for the bytecode of the app that's placed in the image.
The built image uses Java 11 and when the app is built with Java 13
it fails to start as the Java 11 VM can't read that Java 13 bytecode.
This commit configures the app that's placed in the image to be built
with target compatibility of 1.8. This allows it to be compiled with
all version of Java with which we build and to also be compatible
with the JVM that's in the image.
See gh-19831
Update all dependencies declarations to use the form `scope(reference)`
rather than `scope reference`.
Prior to this commit we declared dependencies without parentheses unless
we were forced to add them due to an `exclude`.
Previously, reflective access to the archiveBaseName property
incorrectly treated the property as a String. It should have been
treated as a Property<String>. This caused an exception to be thrown
and the deprecated baseName property to be used as a fallback.
This commit corrects the reflective access to the archiveBaseName
property. It also updates the tests to fail if a build outputs a
deprecation warning. Tests that use Gradle's Maven plugin have been
updated to expect deprecation warnings when run with Gradle 6.0 where
the plugin is deprecated. Tests that configure an archive's base name
have been updated to use archiveBaseName when running with Gradle 6.0
and later.
Closes gh-18663
Previously, our Gradle plugin was not tested against Gradle 6.0,
a number of deprecation warnings were output when using the plugin
with Gradle 6, and some functionality related to the application
plugin did not work as expected.
This commit tests the plugin against Gradle 6. It also avoids calling
deprecated APIs. The plugin is compatibile against Gradle 4.10 where
the deprecated APIs' replacements are not available so reflection is
used to call the replcaements. Lastly, the way in which the base name
of the boot distribution that is created when the application plugin
is applied has been modified to ensure that it is effective when using
Gradle 6.
Closes gh-18663
Update Gradle archive tasks to ensure that `META-INF/` and
`META-INF/MANIFEST.MF` remain as the first entries of the archive.
Prior to this commit, rewritten archives would violate the implicit
specification of `JarInputStream` that these entries should be first.
Fixes gh-16698
This commit removes the need for the Kotlin plugin tests to continue
to set the plugin classpath in each test build script. This is
achieved by adding the jars files containing the Kotlin plugin and
its dependencies to the runner's plugin classpath in the same way as
was already done for the dependency management plugin.
Closes gh-14680
Previously, each test build script used a property to configure its
classpath. This commit simplifies the tests by setting the classpath
once on the GradleRunner, thereby removing the need for it to be set in
each test script. It also allows, and, in fact, requires, the use of
the plugins block to apply the Boot plugin under test.
Unfortunately, this doesn't work for the tests for the reaction to the
Kotlin plugin. See the comments in the GradleBuild class and in each
KotlingPluginActionIntegrationTests build script.
See gh-14680
Previously, if the project's group, name, or version changed the
BuildInfo task would still be considered up-to-date as the values of
the project's properties were not reflected in the fields of the
BuildInfo instance.
This commit updates BuildInfo to copy the value of the project's
property to the corresponding BuildInfo field when the property is
read using its getter method on BuildInfo.
Closes gh-12266
Previously, the ordering of the entries in an archive produced by
BootJar was different to the ordering of the entries in an archive
produced by BootWar. The latter placed application classes before
any nested jars, whereas the former was the other way around.
This commit updates BootJar to use the same ordering as BootWar and
adds tests to verify that the ordering is the following:
1. Loader classes
2. Application classes (BOOT-INF/classes or WEB-INF/classes)
3. Nested jars (BOOT-INF/lib or WEB-INF/lib)
4. Provided nested jars in a war (WEB-INF/lib-provided)
The tests also verify that the position of a library is not affected
by it requiring unpacking.
See gh-11695
See gh-11696
Stop running apply-plugin tests as part of the build since during a
release the version number will change and the jar will not be
available.
Fixes gh-11857
The Gradle plugin integration tests find their Gradle build scripts
using a naming convention of ${ClassName}-${methodName}.gradle. This
convention led to two gradle scripts with filenames that were long
enough to causes problems on Windows.
This commit renames two test methods to reduce the length of their
names and, therefore, the names of their corresponding Gradle script
files.
Closes gh-10868
Previously, the configuration metadata annotation processor relied
upon an additional metadata file have been copied to an output
location. When building with Gradle, it's the processResources task
that performs this copy and there is no guarantee that it will have
run before the compileJava task unless an explicit dependency betwee
the two tasks has been configured. If a project is built using
Gradle's parallel build support, the likelihood of this required
ordering not occurring increases.
This commit updates the configuration metadata annotation processor to
consider a new annotation processor option when looking for the
additional config metadata file. The Gradle plugin has been updated
to provide this option as a compiler argument. The option is only
provided when the annotation processor is found on the compilation
classpath to avoid a warning from javac's annotation processing about
the use of an option that is not supported by any of the available
annotation processors.
Closes gh-9755
This commit introduces a new mainClassName property on the springBoot
DSL provided by the Gradle plugin. It can be used to explicitly
configure the mainClassName of the default bootRun, bootJar, and
bootWar tasks in a single place. Previously, the only mechanism
provided to do so was the mainClassName property that's only available
when the application plugin has been applied.
Closes gh-10623
Previously, BootRun used the main property to configure the name of
the main class to run while BootJar and BootWar used the mainClass
property. Both were different to the application plugin which provides
a mainClassName project property.
This commit updates BootRun, BootJar, and BootWar to change the name
of the property used to configure the name of the main class to be
mainClassName. This makes the three Boot-specific tasks consistent
with each other, and also aligns them with Gradle's own application
plugin.
Closes gh-10622
Move projects to better reflect the way that Spring Boot is released.
The following projects are under `spring-boot-project`:
- `spring-boot`
- `spring-boot-autoconfigure`
- `spring-boot-tools`
- `spring-boot-starters`
- `spring-boot-actuator`
- `spring-boot-actuator-autoconfigure`
- `spring-boot-test`
- `spring-boot-test-autoconfigure`
- `spring-boot-devtools`
- `spring-boot-cli`
- `spring-boot-docs`
See gh-9316
Andy Wilkinson
Stephane Nicoll
Scott Frederick
Paddy Drury
Phillip Webb
dreis2211
Johnny Lim
Madhura Bhave
Spring Operator
jnizet
durigon
Rui Figueira