This commit adds auto-configuration for R2DBC. If R2DBC is on the
classpath, a `ConnectionFactory` is created similarly to the algorithm
used to create a `DataSource`.
If an url is specified, it is used to determine the R2DBC driver and
database location. If not, an embedded database is started (with only
support of H2 via r2dbc-h2). If none of those succeed, an exception is
thrown that is handled by a dedicated FailureAnalyzer.
To clearly separate reactive from imperative access, a `DataSource` is
not auto-configured if a `ConnectionFactory` is present. This makes sure
that any auto-configuration that relies on the presence of a
`DataSource` backs off.
There is no dedicated database initialization at the moment but it is
possible to configure flyway or liquibase to create a local `DataSource`
for the duration of the migration. Alternatively, if Spring Data R2DBC
is on the classpath, a `ResourceDatabasePopulator` bean can be defined
with the scripts to execute on startup.
See gh-19988
Co-authored-by: Mark Paluch <mpaluch@pivotal.io>
With the introduction of Gradle we lost the list of version properties
that were previously in the spring-boot-dependencies POM and were also
linked inside the documentation. This commit introduces an appendix
section in the docs and links the appropriate places to the new section
to restore discoverability.
See gh-19898
This paves the way for publishing Gradle module metadata once the
problem caused by snapshot versions and our two-step publication
process has been addressed.
See gh-19609
This reverts commit b34a311d02 as,
having disabled the publishing of Gradle's module metadata (4f75ab5),
the changes are no longer needed.
See gh-19609
The way in which we deploy the artifacts (publishing to a Maven
repository on the filesystem and then using the Concourse artifactory
resource to upload them) is incompatible with Gradle's module metadata
generation.
The metadata contains an entry, url, that contains the name of the
artifact. This will be something like
spring-boot-gradle-plugin-2.3.0.BUILD-20200114.095038-1.jar. The -1 in
the name is derived from the Maven snapshot build number. It's -1 as
the local repository to which the artifact is published is empty and
has no maven-metadata.xml file. When the artifact is uploaded to
Artifactory there is a maven-metadata.xml file so the build number is
different. As a result, the module metadata points to a file that
doesn't exist. This leads to problems like this when trying to consume
the snapshots:
Could not find spring-boot-gradle-plugin-2.3.0.BUILD-20200114.095038-1-2.3.0.BUILD-SNAPSHOT.jar (org.springframework.boot:spring-boot-gradle-plugin:2.3.0.BUILD-SNAPSHOT:20200114.101952-123)
Gradle has used the maven-metadata.xml file on the server to determine
that 2.3.0.BUILD-SNAPSHOT:20200114.101952-123 is the latest version.
It has downloaded the .module file with this version but it points to
spring-boot-gradle-plugin-2.3.0.BUILD-20200114.095038-1.jar. That file
doesn't exist so the build fails.
See gh-19609
Previously, enforcedPlatform dependencies were using to pull in the
constraints defined in spring-boot-dependencies and
spring-boot-parent and applied them strictly so that the constrained
version had to be used. This worked as intended in Spring Boot's own
build but incorrectly enforced those same strict version requirements
on external consumers of Spring Boot's modules.
This commit reworks how Spring Boot defines its internal dependency
management so that platform dependencies are exposed to external
consumers while enforced platform dependencies are using internally.
See gh-19609
Scott Frederick
Andy Wilkinson
Brian Clozel
dreis2211
Johnny Lim
Mike Smithson
Phillip Webb
Stephane Nicoll
Vedran Pavic