"Starter POM" is a confusing term as it implies the starter may be a
POM while it's actually a jar artifact like any other dependency. To
reduce the confusion (especially in the way such starter should be
declared in the build), the term Starter POM has been renamed to Starter.
Closes gh-5966
This commit deprecates the `ws` starter in favour of a new `web-services`
starter. A deprecation warning auto-configuration has also been added to
the ws starter.
Closes gh-5711
This commit streamlines the Integration Starter by removing the file
http, ip, and stream modules as they are not always used by a majority
of apps that use Spring Integration and can also pull in other, unwanted
dependencies.
Additionally, a dependency on spring-integration-java-dsl has been
added. This makes it easy for users to configure Spring Integration
using Java configuration (the recommended approach), rather than via
XML. The Integration sample has been updated to use the DSL. Further
improvements could be made once the sample is using Java 8.
Closes gh-5528
Rename spring-boot-starter-webservices back to spring-boot-starter-ws.
Unfortunately the starter exists in Spring Boot 1.3 so we can't rename
it without consequence.
See gh-5711
In the web starter we shouldn't depend explicitly on any EL
implementation, otherwise when people build wars and deploy
them in containers that have their own EL there is a conflict.
We can still depend on hibernate-validator to support
JSR-303 in web apps because the EL implementation comes with
the container.
Fixes gh-5454
Previously, the documentation included hand-written tables for the
application, production, and technical starters.
This commit replaces the hand-written tables with tables that are
generated automatically from all of the starter poms, thereby ensuring
that the documentation is automatically kept up-to-date as starters
are added and removed. An extra column provided a link to each
starter's pom on GitHub has also been added to the table. This makes
it easier for users to see exactly what each starter contains.
Closes gh-5267
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
Stephane Nicoll
Johnny Lim
Phillip Webb
Dave Syer
cjstehno
Jan Galinski
Andy Wilkinson
Vedran Pavic
Gytis Trikleris
John Blum
oEmbedler Inc
Michael Hunger
Michael Simons
Charles Harvey III
Mariusz Kopylec
Eddú Meléndez
jvmlet
Ian
Spring Buildmaster
Julien Dubois
Andreas Ahlenstorf
Paweł Lesiecki
Matthias Friedrich