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
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
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
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 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
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
