Previously, Spring Boot's modules published Gradle Module Metadata
(GMM) the declared a platform dependency on spring-boot-dependencies.
This provided versions for each module's own dependencies but also had
they unwanted side-effect of pulling in spring-boot-dependencies
constraints which would influence the version of other dependencies
declared in the same configuration. This was undesirable as users
should be able to opt in to this level of dependency management, either
by using the dependency management plugin or by using Gradle's built-in
support via a platform dependency on spring-boot-dependencies.
This commit reworks how Spring Boot's build uses
spring-boot-dependencies and spring-boot-parent to provide its own
dependency management. Configurations that aren't seen by consumers are
configured to extend a dependencyManagement configuration that has an
enforced platform dependency on spring-boot-parent. This enforces
spring-boot-parent's version constraints on Spring Boot's build without
making them visible to consumers. To ensure that the versions that
Spring Boot has been built against are visible to consumers, the
Maven publication that produces pom files and GMM for the published
modules is configured to use the resolved versions from the module's
runtime classpath.
Fixes gh-21911
Pick up the workaround for the AsciidoctorJ bug that prevents the
configprops macro's attributes from being parsed. The lack of parsing
meant that the envvar format was being lost and properties were being
written in the canonical form instead.
Closes gh-21794
Previously, dependency management for JNA was provided by
spring-boot-dependencies so it affected users' applications. It was
original added for Elasticsearch but is no longer needed for that
purpose. We use JNA in spring-boot-buildpack-platform which is used
by our Gradle and Maven plugins and should not affect an application's
use of JNA.
This commit moves management of JNA from spring-boot-dependencies into
spring-boot-parent. This means that users' applications will now be
free to use whatever version of JNA meets their needs while still
controlling the version used for image building via Gradle or Maven.
Closes gh-20156
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`.
Replace Gradle single quote strings with the double quote form
whenever possible. The change helps to being consistency to the
dependencies section where mostly single quotes were used, but
occasionally double quotes were required due to `${}` references.
Previously, Maven's default behaviour was relied up which resulted
in the artifact ID being appended to each URL as it was inherited.
This behaviour can only be disabled in Maven 3.6 and later, a version
that we cannot use due to an incompatibility with the Flatten Plugin.
This commit works around Maven's default behaviour by defining
properties for the SCM URL, connection, and developer connection and
then explicitly defining the settings in each pom using these
properties. The explicit definition of the properties in each pom
prevents them being inherited from the parent, thereby disabling the
unwanted appending of the artifact ID to the URL.
Fixes gh-18328
This commit introduced an incompatible change in the asciidoct
API: both asciidoctorj-pdf and spring-asciidoctor-extensions
expect `org.asciidoctor.extension.JavaExtensionRegistry` to be
a class, not an interface.
This reverts commit 120ffb1ed0.
This commit replaces the Docbook+Asciidoctor documentation toolchain by
a single Asciidoctor generation process.
First, we need to unzip the contents of the Spring Asciidoctor
documentation resources provided by the
`io.spring.docsresources:spring-docs-resources` distribution zip. This
is done in a `/target/refdocs` folder. We then copy all files from
`src/main/asciidoc` to the same location, and then launch the generation
process.
Closes gh-12611