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>
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
Stephane Nicoll
Andy Wilkinson