Add AssertJ as a managed dependency and also include it in
spring-boot-starter-test. Also provide a simple adapter class to allow
Hamcrest matchers to be used as AssertJ Conditions.
Fixes gh-5048
Our Investigations show that JNDI lookup is quite costly on Jetty and it
was enabled by default while embedded tomcat does not. This commit
excludes `jetty-jndi` to align the behavior with Tomcat.
If you are relying on JNDI, the `jetty-jndi` should simply be added in
your project.
Closes gh-4710
So far we have wrongly advertized that the `spring-boot-starter-parent`
filters application configuration in such a way that standard Spring
placeholders are not processed.
In order to achieve such feature, the `useDefaultDelimiters` property
must be set to `false` as otherwise default delimiters are appended to
the list of custom delimiters.
This property is not enabled so that only keys surrounded by `@` are
filtered by the build.
Closes gh-3092
AspectJ’s weaver module contains a superset of the classes found in
AspectJ’s RT module. This commit updates the starters to exclude
aspectjrt so that only aspectjweaver is on the classpath.
Closes gh-3975
GemFire 8.0 depends on two different versions of xml-apis:xml-apis and
org.eclipse.jdt.core.compiler:ecj. This commit adds dependency
management for those two dependencies to address the dependency
convergence errors reported by Maven’s enforcer plugin.
GemFire 8.0 also depends on commons-logging and Spring Boot starters
should use jcl-over-slf4j instead. This commit adds an exclusion for
commons-logging
GemFire 8.0 depends (optionally) on spring-data-gemfire and
spring-data-gemfire depends on GemFire, i.e. there’s a dependency cycle
between the two projects. This commit breaks this cycle by adding an
exclusion for spring-data-gemfire to the dependency management for
com.gemstone.gemfire:gemfire.
This commit should be reverted once the problems with GemFire’s
dependencies have been addressed. See gh-2884.
Initial update to the documentation to mention how a 3rd party starter
should be named. The current doc sends a completely inconsistent message
to what we actually intend.
See gh-2537
Previously, the only starter that provided validation was
spring-boot-starter-web which included Hibernate Validator and
Tomcat's EL implementation. This left users writing non-web
applications to figure out the dependencies for themselves. They would
sometimes run into difficulties as Hibernate Validator's need for an
EL implementation would trip them up.
This commit adds a new starter, spring-boot-starter-validation,
which provides both Hibernate Validator and Tomcat's EL
implementation. spring-boot-starter-web has been updated to depend on
this starter rather than depending on Hibernate Validator directly.
Closes gh-2678
The documentation claims that JSPs don't work with embedded Jetty
making the dependency on jetty-jsp pointless. Furthermore,
spring-boot-starter-tomcat doesn't include JSP support and Undertow
doesn't support JSPs at all so removing jetty-jsp makes the embedded
container starters more consistent. It also removes 3.2MB from a
Jetty-based fat jar (spring-boot-sample-jetty drops from 12MB to
8.8MB).
Closes gh-2680
This commit replaces Spring Boot's basic dependency management support
with separate dependency management plugin. This has a number of
benefits including:
1. A Maven bom can be used rather than a custom properties file
2. Dependency management is applied transitively rather than only to
direct dependencies
3. Exclusions are applied as they would be in Maven
4. Gradle-generated poms are automatically configured with the
appropriate dependency management
Closes gh-2133
A dependency on org.glassfish.jersey.ext:jersey-bean-validation has
been added to spring-boot-starter-jersey. jersey-bean-validation’s EL
dependencies have been excluded in favour of those provided by
spring-boot-starter-tomcat (or starter-jetty or starter-undertow should
the user choose to use a different embedded container).
Closes gh-2315
The package names changed a bit from the prototype project, but wuth vanilla
autconfiguration usage that shouldn't matter. Follows closely the Groovy
templates support. Templates live in classpath:/templates/*.html by default.
Fixes gh-2242
Sadly, Gradle handle's exclusions differently to Maven even when it's
processing a Maven pom.
In this case groovy-all is pulled in via org.crashub:crash.shell where
we've excluded it. This is enough to prevent Maven from pulling in
groovy-all when you depend on the remote shell starter.
org.crashub:crash.shell is also pulled in as a transitive dependency
of a number of other dependencies and Gradle requires each of these
to also exclude groovy-all for it to actually be excluded.
This commit adds the additional exclusions that are required to make
Gradle's behaviour sane.
Fixes gh-2257
Update maven-jar-plugin configuration in spring-boot-starter-parent
with `addDefaultImplementationEntries` so that implementation versions
are included by default.
Fixes gh-2266
Mixing Hibernate and a JTA provider may lead to duplicate JTA
dependencies as the API is published with different coordinates.
The following has been applied:
* We now use `javax.transaction:javax.transaction-api` everywhere.
* The `data-jpa` starter has been updated to replace the JBoss JTA
dependency with the standard one.
* The `jta-bitronix` starter has been updated to use JTA 1.2 instead of
JTA 1.1 (unfortunately, JTA 1.1 is published with different
coordinates).
* The `jta-atomikos` starter has been updated to define a dependency on
JTA as the current version does not do it at all.
* The HornetQ JMS server is also relying on JTA but that dependency
should have been optional. It has been excluded for the time being as
it was using (yet) another set of coordinates.
Fixes gh-2092
Unlike the Tomcat and Jetty starters, the Undertow starter does not
provide an EL implementation. This leads to failures when you try to use
Hibernate Validator with the Undertow starter.
To bring the Undertow starter into line with the other two embedded
container starters, this commit adds Glassfish’s EL implementation to
the Undertow starter. This is the implementation that’s used by the
Jetty starter. If/when Undertow provides JSP support and, therefore,
starts using EL itself, we should align with it.
Closes gh-1979
Including maps and lists. Beans with no metadata (in
/META-INF/*spring-configuration-metadata.json) are just serialized
as they come (so might have problems like cycles). Serialization
errors are caught and rendered as an "error" for that bean. Any
problems can be fixed by preparing metadata and specifying which
properties are to be rendered that way.
Fixes gh-1746, fixes gh-1921
This commit reworks a7e1ec8 to fix the build failure and update the
documentation regarding default maven filtering option with
spring-boot-starter-parent
Fixes gh-1199
It *is* very useful to have filtering on by default, so that is now
the case (in spring-boot-starter-parent). Users can filter resources
by default by adding @*@ placeholders (so as not to clash with Spring
${} placeholders).
Fixes gh-1199
Spring IO Platform already provides dependency management for JavaMail.
This commit updates Boot’s new JavaMail dependency management to align
with the Platform, thereby allowing the Platform to inherit Boot’s
dependency management instead of defining its own.
This commit adds a new starter to auto-configure a MailSender when the
necessary classes are present and when the property "spring.mail.host" is
set.
The auto-configuration also accepts any arbitrary properties that
JavaMail might need using the "spring.mail.properties" prefix.
Fixes gh-1760
Remove the maven-antrun-plugin from the pluginManagement section of
spring-boot-starter-parent since it is already declared in the
spring-boot-dependencies POM.
Closes gh-1688
Add `maven.compiler.source` and `maven.compiler.target` properties to
the spring-boot-starter-parent to allow easier customization of the
maven compiler. Both properties default to `${java.version}`.
Fixes gh-1684
Jersey 2 has some Spring support built in but it's a bit awkward to
use in a Boot app, so autoconfiguration seems appropriate. The tests
and sample show how to use it, but the short story is that any
@Component can define JAX-RS endpoints via @GET etc.
There's a sample for Jersey 1 as well (pay careful attention to
the plugin configuration if you want to build an executable jar)
Fixes gh-1651
Spring Data Redis 1.4.0 introduced Redis Sentinel support. When
specified, RedisConnectionFactory uses the Sentinel configuration to
determine the current master.
Sentinel configuration can be specified using two new properties:
spring.redis.sentinel.master and spring.redis.sentinel.nodes.
For example:
spring.redis.sentinel.master=mymaster # name of redis server
spring.redis.sentinel.nodes=127.0.0.1:26379,127.0.0.1:26380
Alternatively, a bean of type RedisSentinelConfiguration can be declared
and it will be used to configure the connection factory.
Note: At this time, Sentinel support is only available for Jedis
Closes gh-1337
The Maven plugin version numbers are defined in the pluginManagement
of the spring-boot-dependencies pom.xml. Consequently, they can be
deleted in the spring-boot-starter-parent pom.xml to avoid version
conflicts and duplicated version management.
Prior to this commit, when used with Gradle, spring-boot-starter-ws was
pulling in the versions of spring-jms, spring-oxm, and spring-tx that
Spring WS depends upon, rather than using the Boot’s Spring version.
It’s ok at the moment as both Boot and Spring WS depend on Spring 4.0.5
but will cause problems if we upgrade to 4.0.6 before Spring WS does.
This commit adds explicit dependencies on spring-jms and spring-oxm so
that Gradle pulls in the correct version (as long as a transitive
dependency doesn’t pull in a version that’s greater than the version
Boot’s using).
Simplify the exclusion logic used in Gradle by implementing implicit
exclusions rather than trying to detect transitive excludes.
This commit reverts much of the code originally included to fix gh-1047
which adds far too much complexity to the build and still doesn't solve
the underlying issue.
Fixes gh-1103
Remove superfluous dependencies from spring-boot-starter-tomcat and
spring-boot-starter-jetty which caused gradle based builds to put
too many libraries in `/lib-provided` when building a war.
Fixes gh-1064
- upgraded Spring WS to 2.2.0.RELEASE
- replaced default MVC DispatcherServlet with MessageDispatcherServlet
- migrated XML based config with nww Spring WS Java config
Fixes: gh-412
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 196f92bd42
See gh-1047
Update spring-boot-versions to generate a dependency-tree file and
attach it as an artifact. The file is generated by creating a temporary
POM and calling the invoker plugin.
The spring-boot-versions POM now depends on all spring-boot-starter-*
POMs to ensure that they have been installed before the dependency
tree is processes.
See gh-1047
Due to the lack of dependency management in Gradle a number of the
starters were pulling in old versions of spring-tx (and in some cases
spring-context-support as well) as the only dependency was a
transitive one that pulled in an older version.
This commit adds explicit dependencies on spring-context-support and
spring-tx where appropriate. These dependencies will specify Boot's
preferred version of Spring causing Gradle to do the right thing as it
prefers the latest version of a dependency when there is more than one
to choose from.
Fixes#1028
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
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
Provide auto-configuration support for HornetQ JMS broker, along with
an additional starter POM.
The connection factory connects to a broker available on the local
machine by default. A configuration switch allows to enable an embedded
mode that starts HornetQ as part of the application.
In such a mode, the spring.hornetq.embedded.* properties provide
additional options to configure the embedded broker. In particular,
message persistence and data directory locations can be specified. It is
also possible to define the queue(s) and topic(s) to create on startup.
Fixes: gh-765
Phillip Webb
jvmlet
Ian
Stephane Nicoll
Spring Buildmaster
Eddú Meléndez
Mariusz Kopylec
Andy Wilkinson
Julien Dubois
Andreas Ahlenstorf
Paweł Lesiecki
izeye
Dave Syer
Matthias Friedrich
sopov.ivan
Domingo Suarez Torres
Gotzon Illarramendi
Michael Vitz
Daniel Fullarton
Christoph Strobl
Ramnivas Laddad
Josh Long
Mattias Severson
Dave Syer
Stephane Nicoll
Andy Wilkinson
Phillip Webb
Maciej Walkowiak
Marten Deinum
Artur Konczak