To be compatible with Gradle's plugin portal, plugins must have an
ID that uses a reverse domain name. This means that spring-boot is
not compatible.
This commit introduces a new ID, org.springframework.boot, and
deprecates the old ID.
Closes gh-6997
The cache abstraction is a core feature of the Spring Framework. Basic
features such as `@EnableCaching` are therefore available by default with
no extra dependencies necessary.
However, the actual cache adapters for JCache, Ehcache 2.x, Caffeine and
Guava are located in a separated module, `spring-context-support`. Spring
Boot provides that artifact via the `spring-boot-starter-cache` starter.
It is quite easy to "only" add the cache library dependencies and forget
about this extra dependencies since `@EnableCaching` is available by
default. This commit clarifies the role of the starer in each section so
that it is more obvious. We're already explaining this at the beginning
of the section but it seems that's not enough.
Closes gh-7071
Add an explicit note that states that "spring.datasource.url" (or more
specifically "spring.datasource.class-name" that is inferred from the
former) is necessary to connect to a database. If the class-name isn't
specified, Spring Boot will attempt to auto-configure an embedded
database.
Closes gh-6907
This commit improves the startup error message so that it does not
reference `--debug` anymore. Such command-line switch only works when
the application is started using `java -jar`.
The error message now refers directly to a section of the documentation
that provides more details and links to more useful examples.
Closes gh-6593
Breaking API changes in Gradle 3.0 make it impossible to support
it reliably alongside Gradle 1 and 2 without mainintaining multiple
versions of our Gradle plugin. This commit updates the documentation
to note that Gradle 3 is not supported.
Closes gh-6880
This commit adds a new `spring.thymeleaf.check-template` property which
is only used for Thymeleaf 3.0+.
Since thymeleaf/thymeleaf#419, the Thymeleaf template resolver
implementations can implement the `setCheckExistence` method - this
enables the template existence verification at **resolution** time,
which means the resolver can return null as a `TemplateResolution`
and let other template resolvers in the chain try.
This new property is set to `true` by default and can be disabled if the
application only has a single resolver and the template existence check
is considered as a performance penalty with the configured resolver.
Fixes gh-6500
This commit adds the `spring.http.multipart.resolve-lazily`
property, in order to configure whether the multipart request
should be resolved lazily, as the parameters are accessed.
When extending `WebMvcConfigurerAdapter`, developers should always
declare those as `@Configuration` classes rather than `@Bean`s, which
can lead to dependency issues as described in #6853.
Fixes gh-6853
This commit adds `JdbcTemplateAutoConfiguration` to the list of auto-
configurations that are applied with `DataJpaTest`. This effectively
allows to inject a `JdbcTemplate` in any `@DataJpaTest` test.
Closes gh-6802
Rework commit 4a69755b to remove the need for the ApplicationInfo class.
The updated code now uses the auto-configuration class to compute a
default persistence unit root location
Closes gh-6635
Due to the layout format change in 1.4, Spring Framework is no longer
able to compute a default persistence unit root URL. If a Spring Boot 1.4
application has JPA but does not have any entity, the application started
from a fat jar now fails with a quite cryptic exception.
This commit introduces `ApplicationInfo` as a general replacement for
the `ApplicationArguments` and `Banner` singleton beans that
`SpringApplication` registers on startup. `ApplicationInfo` also defines
the detected "main" `Class` that can be used to compute a last resort
URL that makes sense.
If such bean is available, `EntityManagerFactoryBuilder` now sets the
default persistence unit root location, preventing Spring Framework to
attempt to resolve an unknown location. Note that in our case the
persistence unit root location is actually useless: given the way the
persistence unit is created, nothing actually uses it but Hibernate, as a
compliant JPA provider, has to make sure this setting is set to a valid
URL nevertheless.
Closes gh-6635
