17 Commits

Author SHA1 Message Date
Spring Buildmaster
60725cd8bd Next development version 2015-01-07 23:37:07 -08:00
Spring Buildmaster
1a788c1741 Next development version 2014-12-10 16:35:50 -08:00
Stephane Nicoll
249e09d9bc Switch master to 1.2.0.BUILD-SNAPSHOT 2014-07-11 10:44:05 +02:00
Spring Buildmaster
40327e1ae6 Next development version 2014-07-08 02:33:36 -07:00
Spring Buildmaster
981669b7c0 Next development version 2014-06-26 14:09:54 -07:00
Phillip Webb
200cd535c2 Revert "Next development version"
This reverts commit 67189477fe9db7a1e4c5268886868221ca6d2628.
2014-06-26 11:03:09 -07:00
Spring Buildmaster
67189477fe Next development version 2014-06-26 10:51:35 -07:00
Spring Buildmaster
542f3cbda8 Next development version 2014-06-24 13:53:56 -07:00
Spring Buildmaster
4ca26a21dc Next development version 2014-06-11 10:46:27 -07:00
Spring Buildmaster
05ed7b3bcd Next development version 2014-06-10 12:40:35 -07:00
Phillip Webb
3007a777d0 Roll back to 1.1.0.BUILD-SNAPSHOT 2014-06-10 09:00:08 -07:00
Spring Buildmaster
c650f2391e Next development version 2014-06-09 21:55:19 -07:00
Phillip Webb
933c6b3a43 Remove superfluous commons-logging excludes
Update all starter POMs to remove commons-logging dependencies that are
not longer required when using the Spring Boot Gradle plugin.

Mainly reverts code from 196f92bd422778aebe5706b84cc8ffe9bc298878

See gh-1047
2014-06-09 00:41:30 -07:00
Andy Wilkinson
196f92bd42 Exclude commons-logging to the extent that even Gradle’s happy
Gradle hasn’t different exclusion semantics to Maven. In Maven you can
exclude spring-core’s commons-logging dependency once and it’ll be
honoured even if you have multiple transitive routes to commons-logging
via spring-core. In Gradle you have to exclude commons-logging from
everything that has a transitive spring-core dependency. To make matters
worse this doesn’t only apply to dependencies and exclusions declared in
build.gradle but also to dependencies and exclusions declared in the pom
files of the artifacts that a Gradle build depends upon.

In short, to make our starters work as intended with Gradle, this commit
adds many, many exclusions for commons-logging. It also removes
commons-logging exclusions from spring-boot-dependencies’
<dependencyManagement> as they have no effect with Gradle and their
presence can cause us to miss required exclusions in a starter

Fixes #987
2014-06-04 17:40:36 +01:00
Phillip Webb
c719ab7aee Exclude commons-logging from starter POMs
Update all relevant starter POMs to include a `spring-core` dependency
with an exclusion on `commons-logging`. This prevents `commons-logging`
and `jcl-over-slf4j` from both being on the classpath.

Also add enforcer rules to ensure that commons-logging doesn't sneak
back in, and that there is no dependency convergence. (some additional
libraries were required in spring-boot-dependencies)

Tested with a sample maven project as well as using the `spring jar`
command.

Fixes gh-985
2014-05-31 01:10:06 +01:00
Stephane Nicoll
33082fd56d Harmonized maven dependency management
This commit harmonizes the dependency management of internal modules
so that versions can be omitted everywhere. Update the maven coordinates
to provide the full groupId for consistency
2014-05-05 14:29:01 +01:00
Andy Wilkinson
7c91176186 Add FreeMarker support
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
2014-04-29 19:46:09 +01:00