Previously, spring-boot-dependencies listed a subset of Spring
Security's modules. This commit updates it to import Spring Security's
bom instead, thereby providing dependency management for every
module in Spring Security.
Closes#760
We still prefer Tomcat if it is available (that can change
if the community asks loudly enough). Hikari is supported
via the same spring.datasource.* properties as Tomcat (and
DBCP), with some modifications:
* The validation and timeout settings are not as fine-grained
in Hikari, so many of them will simply be ignored. The most
common options (url, username, password, driverClassName) all
work as expected.
* The Hikari team recommends using a vendor-specific DataSource
via spring.datasource.dataSourceClassName and supplying it with
Properties (spring.datasource.hikari.*).
Hikari prefers the JDBC4 isValid() API (encapsulates vendor-
specific queries) which is probably a good thing, but we
haven't provided any explicit support or testing for that yet.
Fixes gh-418
This commit adds auto-configuration and a starter,
spring-boot-starter-freemarker, for using FreeMarker view templates in
a web application.
A new abstraction, TemplateAvailabilityProvider, has been introduced.
This decouples ErrorMvcAutoConfiguration from the various view
technologies that Spring Boot now supports, allowing it to determine
when a custom error template is provided without knowing the details of
each view technology.
Closes#679
Salvatore has indicated that Jedis is his Java Redis client of choice.
This commit updates the auto-configuration support, actuator and
Redis starter accordingly.
Completes #745
The dependencies pom.xml now declares an import to the spring-data-releasetrain BOM pom.xml which in turn constraints version numbers for a dedicated release train release. This has the effect of users being able to upgrade to a certain release train by redeclaring the spring-data-releasetrain.version property to e.g. Dijkstra-M1. Individual modules can be upgraded by simply declaring the dependency in the desired version manually in a <dependencies /> or <dependencyManagement /> block.
Removed the explicit declaration for Spring HATEOAS as it is pulled in transitively by Spring Data REST anyway and thus makes sure it's in a compatible version.
Hibernate is picky about javassist, but unfortunately that
library is used by other parts of our stack (Thymeleaf!?), so
we need a policy for resolving the dependency transitively.
I fixed it to the version in Hibernate 4.3.1 (our current
best foot forward), but it will have to be updateed whenever
Hibernate is.
Fixes gh-402
