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
Update spring-boot-dependencies to include all Jetty modules. The helps
to prevent issues when modules are pulled in transitively (for example
via solr).
Fixes gh-2180
Add auto-configuration for thymeleaf-extras-conditionalcomments which
allows parsing of conditional comments for IE.
Example:
<!--[if lt IE 8]>
<link rel="stylesheet" th:href="@{/styleIE.css}"
type="text/css"/>
<![endif]-->
Without this dialect all Thymeleaf attributes are ignored inside the
comment.
Fixes gh-2113
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
Add a companion module that IDE developers can use to read configuration
metadata from multiple sources into a single repository.
ConfigurationMetadataRepository provides access to groups and items as
well as an harmonized view on "sources" (that is the POJOs that have
contributed to a given group).
Closes gh-1970
hibernate-jpamodelgen was requested by a Boot user. hibernate-ehcache
and hibernate-envers were requested by a Spring IO Platform user (see
spring-io/platform#11
Closes gh-1896
The exception message for a connection timeout has been updated to
include the timeout period. The tests for the sample have been updated
accordingly.
Closes gh-1884
Traditionally, a @ServerEndpoint-annotated bean is found by a servlet
container initialiser, however Boot does not run servlet container
initialisers when an embedded container is being used. To be able to use
@ServerEndpoint in a Boot app that uses embedded Tomcat a
ServerEndpointExporter bean must be declared.
This commit updates the documentation to describe this requirement and
also updates the WebSockets sample to illustrate the use of
ServerEndpointExporter. The version of Spring Framework has been updated
to 4.0.8.BUILD-SNAPSHOT. This picks up the fix for SPR-12340.
Closes gh-1722
This commit updates Spring Boot to Liquibase 3.3.0 and makes the
necessary changes to Boot's PackageScanClassResolver.
Previously, when a class found by the scan could not be loaded a
warning message was logged. This commit lowers these to debug level,
bringing them into line with logging that the standard Liquibase
implementation does. It also avoids a warning always being logged at
startup due to Liquibase's WatchCommand$DynamicContentHandler which
depends on Jetty (an optional dependency of Liquibase).
Closes gh-1382
Upgrade to latest versions of Tomcat and Jetty and to the latest Servlet
API whilst will remaining compatible with Tomcat 7 and Jetty 8.
Fixes gh-1832, gh-369
Adds an annotation processor to generates a JSON meta-data file at
compile time from @ConfigurationProperties items. Each meta-data file
can include an array or 'properties' and 'groups'.
A 'property' is a single item that may appear in a Spring Boot
'application.properties' file with a given value. For example,
'server.port' and 'server.context-path' are properties. Each property
may optionally include 'type' and 'description' attributes to provide
the data type (e.g. `java.lang.Integer`, `java.lang.String`) and
some short documentation (taken from the field javadoc) about what the
property is for. For consistency, the type of a primitive is translated
to its wrapper counterpart, i.e. `boolean` becomes `java.lang.Boolean`.
A 'group' provides a higher level grouping of properties. For example
the 'server.port' and 'server.context-path' properties are in the
'server' group.
Both 'property' and 'group' items may additional have 'sourceType' and
'sourceMethod' attributes to indicate the source that contributed them.
Users may use `META-INF/additional-spring-configuration-metadata.json`
to manually provide additionally meta-data that is not covered by
@ConfigurationProperties objects. The contents of this file will be
read and merged with harvested items. The complete meta-data file is
finally written to `META-INF/spring-configuration-metadata.json`.
See gh-1001
This commit adds a new command to the CLI that allows to initialize a new
project from the command line. It uses the Spring initializr service to
actually generate the project.
The command offers two main operations:
1. Listing the capabilities of the service (--list or -l). This basically
dumps the defaults of a given service and the list of dependencies and
project types it supports
2. Generating a project. By default, http://start.spring.io is used and
its configured defaults are applied. Running spring init would therefore
have the same effect as clicking the 'generate project' on the UI without
entering any extra information. No file is overwritten by default.
The generation can be customized with the following options:
* --boot-version (-bv) Spring Boot version the project should use
* --dependencies (-d) comma separated list of dependencies to add to the
generated project
* --java-version (-jv) Java version to use
* --packaging (-p) the packaging for the project (jar, war)
* --target the url of the service to use
The actual type of the project can be defined in several ways:
1. Using the --type (-t) option that identifies a type that is supported
by the service
2. A combination of --build and/or --format that can be used to uniquely
identify matching these tags. Build represents the build system to use
(e.g. maven or gradle) while --format defines the format of the generated
project.
The project is saved on disk with the name provided by the server through
the Content-Disposition header, if any. It is possible to force it with
the --output option. It is possible to overwrite existing files by adding
the --force (-f) flag.
The --extract (-x) option allows to extract the project instead of saving
the zip archive. By default, the project is extracted in the current
working directory but it is possible to specify an alternate directory
using the --output option.
Fixes gh-1751
Andy Wilkinson
Dave Syer
Phillip Webb
Spring Buildmaster
Stephane Nicoll
Michael Cramer
Sebastien Deleuze
sopov.ivan
Nathan Voxland