Previously, the JDK 10 build would fail as we build the plugin using
Gradle 4.0.x (the lowest version of Gradle that we support) and
Gradle 4.0.x doesn't work with Java 10.
Upgrading to Gradle 4.1, which appears to work with Java 10, was
considered but rejected for now as it introduces the risk that we
inadvertently use an API that's new in 4.1 and break our 4.0 support.
This commit goes for the extreme option and disables building the
Gradle Plugin when building with JDK.
See gh-12028
Spring Integration no longer requires a `MicrometerMetricsFactory` to
support Micrometer metrics so there's nothing for Boot to
auto-configure.
See gh-12287
Prior to this commit, the `ApplicationContext` couldn't start with a
JDK-proxied `HikariDataSource` as the JMX auto-configuration was
attempting to inject a (too narrowed) `HikariDataSource`.
This commit rather injects a regular `DataSource` and attempt to unwrap
it as a `HikariDataSource`.
Closes gh-12271
Reactor Netty 0.7.5 now supports all Compression options.
Unlike previous Reactor Netty versions, the minimum compression
threshold is now based on the content-length instead of
accumulating for a while the data.
See gh-12268
Update `EndpointRequest` to that the `PathMappedEndpoints` bean is
optional. A missing bean is treated as if there are no path mapped
endpoints.
Fixes gh-12238
Update `ApplicationContextRequestMatcher` and
`ApplicationContextServerWebExchangeMatcher` to use a supplier for
the context, rather than the context itself.
This allow exceptions to be propagated to subclasses which may choose
to deal with them.
See gh-12238
Update `spring-boot-actuator-autoconfigure` so that it no longer has
a dependency on `spring-boot-test-autoconfigure`. This will allow us to
add test support for actuator concerns in the future if we need to.
Fixed gh-12270
This commit simplifies the HTTP compression configuration for Reactor
Netty servers.
Also, this commit removes a test for the
`server.compression.min-response-size` support, as this is only
supported when the HTTP response contains a `Content-Length` header.
Since most Spring WebFlux responses are using
`Transfer-Encoding: chunked`, we should not test for that case.
See gh-12268
