If spring-hateoas is on the classpath and an MvcEndpoint returns a
@ResponseBody it will be extended and wrapped into a Resource with links.
All the existing endpoints that return sensible JSON data can be extended
this way (i.e. not /logfile). The HAL browser will also be added as an
endpoint if available on the classpath. Finally, asciidocs for the
Actuator endpoints are available as a separate jar file, which if
included in an app will also generate a new (HTTP) endpoint.
Fixes gh-1390
Previously, the CLI’s dependency management used proprietary Properties
file-based metadata to configure its dependency management. Since
spring-boot-gradle-plugin’s move to using the separate dependency
management plugin the CLI was the only user of this format.
This commit updates the CLI to use Maven boms to configure its
dependency management. By default it uses the spring-boot-dependencies
bom. This configuration can be augmented and overridden using the new
@DependencyManagementBom annotation which replaces @GrabMetadata.
Closes gh-2688
Closes gh-2439
Updates to prevent the maven-invoker-plugin from downloading remote
snapshot jars. Possibly caused by the recent changes to the
spring-boot-dependencies POM.
See gh-1413
Add a repositories section to the spring-boot-dependencies POM but
strip it out during a CI build. This allows snapshot and milestone
BOM imports to be used but doesn't pollute published POMs and doesn't
prevent a fresh checkout from building.
Fixes gh-1413
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
- 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
Add a new maven project containing a versions.properties file and
an effective POM. Rework existing projects to use the versions
artifacts.
Partially reverts 307fbba9e4
Fixes gh-913
Use `maven-failsafe-plugin` to run CLI integration tests as part of
the `spring-boot-cli` project, removing the need for
`spring-boot-cli-integration-tests`.
Previously, Aether's configuration was largely hard-coded making it
impossible to configure a mirror, provide credentials for accessing
a repository, etc.
This commit adds support for configuring Aether via Maven's
settings.xml file. The support is optional and must be enabled by
grabbing spring-boot-maven-settings in an init script. The Aether
instance that's used when running the application will then be
configured using settings.xml. The settings file is expected to be
found in ${user.home}/.m2/settings.xml.
The configuration of the following items is currently supported:
- Offline
- Proxies
- Mirrors
- Server authentication
- Local repository location
If the support is not enabled, settings.xml does not exist, or
settings.xml does not configure certain things then sensible defaults
are applied.
By default it is on, but you can switch it
off (`-P '!integration'`) to ignore integration tests
and get a faster build.
.travis.yml uses this feature so that it doesn't keep
failing on a timeout.
Rework classloading for launched applications so that CLI classes and
dependencies are not visible. This change allows many of the previous
hacks and workarounds to be removed.
With the exception of the 'org.springframework.boot.groovy' package
and 'groovy-all' all user required depndencies are now pulled in
via @Grab annotations.
The updated classloading algorithm has enabled the following changes:
- AetherGrapeEngine is now back in the cli project and the
spring-boot-cli-grape project has been removed. The AetherGrapeEngine
has also been simplified.
- The TestCommand now launches a TestRunner (similar in design to the
SpringApplicationRunner) and report test failures directly using
the junit TextListener. Adding custom 'testers' source to the users
project is no longer required. The previous 'double compile' for
tests has also been removed.
- Utility classes have been removed in favor of using versions from
spring-core.
- The CLI jar is now packaged using the 'boot-loader' rather than using
the maven shade plugin.
This commit also applied minor polish refactoring to a number of
classes.
Prior to this commit, the Aether-based GrapeEngine was loaded in the
same class loader as the rest of Boot. This led to Aether's and its
dependencies' types polluting the application's class path. Most
notably, this caused problems with logging as the logging framework
could be permaturely initialized.
This commit isolates AetherGrapeEngine, Aether and its dependencies
into a separate class loader. This is done by customizing the
packaging of the CLI's jar file with the internal directory housing
all of the types that will be loaded by the separate class loader.
Usually, use of @Grab requires you to specify a group, module, and
version when identifying a dependency. This can be done in two
different ways:
@Grab(group='alpha', module='bravo', version='1.0.0')
@Grab('alpha:bravo:1.0.0')
This commit allows users to only specify a module: the group is
inferred and the version is the one dictated by the boot CLI. Both
forms are supported:
@Grab(module='bravo')
@Grab('bravo')
Groovy's global AST transformations, which is how Grab is implemented,
do not support ordering and we need to augment the AST for the Grab
annotation before its processed by the Grab AST transformation. To
work around this, reflection is used to get hold of the compile
operations in the conversion phase, and a new AST transformation is
inserted immediately before the first AST transformation operation.
To allow a module's groupId and version to be resolved consistently,
META-INF/springcli.properties has been enhanced to include properties
for each module that we want to support in the following form:
<module>.groudId = <groudId>
<module>.version = <version>
<groupId> and <version> are taken from the Maven project's
dependencies and VPP, a Velocity-based pre-processor, is used to
automatically generate the enhanced properties file.
To prevent pollution of spring-boot-cli's class path with the
dependencies that are only required to populate springcli.properties,
a separate project, spring-boot-cli-properties, has been created.
spring-boot-cli depends upon this now project causing it to, via the
shade plug, include the properties file in its jar.
Previously DependencyCustomizer allow a dependency to be added by
specifying its full coordinates, i.e. a group ID, artifact ID, and
version. This commit updates DependencyCustomizer to only require
an artifact/module ID. The group ID and version are then resolved
using the same mechanism as the enhanced @Grab support.
[#56328644] [bs-312] Allow @Grab without version
Rework main build POM to be an aggregator pom that does not inherit
from any parent. Introduce new spring-boot-dependencies module to
act as a parent for both spring-boot-starter-parent and
spring-boot-parent.
Create spring-loader-tools containing utilities that can be used
with both Maven and Gradle plugings.
Refactored existing Maven plugin to use the new project.
Issue: #53129653
* Make Rector @Autowirable
* Create a ConsumerBeanPostProcessor so users can add
@On and @Reply to bean methods
* Added groovy auto compiler and script sample
[#53955419] [bs-250]
Add a setup profile allowing the maven plugin to be build alone.
Required to prevent 'unresolveable build extension' errors on a
fresh checkout.
Issue: #52091115
Develop a maven plugin that can be used to package executable jar/war
archives. The plugin is intended to be used as a drop-in replacement
for the standard maven-jar-plugin. To use the plugin declare it with
<extensions>true</extensions> then set the project type to
'executable-jar' or 'executable-war'.
Configuration options for 'executable-war' generation are intentionally
much more limited then the standard maven-war-plugin (for example
overlays are not supported). It is anticipated that builds requiring
complex configuration will continue to use the standard plugin in
combination with a custom assembly.
Issue: #52091115
User adds @OnManagementContext to a bean or @Configuration and
it should be included in the management context (if there is one)
whether it is the main context or a child.
Makes it easy to secure the management endpoints and keep
the rest open (see actuator-ui-sample).
[#50721675]
* Added GroovyTemplate.template() utility and static import in webapp CLI, so
@RequestMapping("/")
@ResponseBody
String home(Model model) {
template "home.html", model
}
renders the template in /templates/home.html
[Fixes#49832753]
* MessageSource created automatically (location
spring.messages.basename:messages)
* Thymeleaf configured automatically to look for
templates in classpath:/templates
* Added static resource handlers for classpath:/static
and classpath:/
[Fixes#49832165] [bs-118] Support for thymeleaf templates
* Suport maven-exec-plugin in the same way as the shade plugin, so
$ mvn exec:java
is all you need to do to run an app
* Update README
* Fix dependencies to nail Spring version
* Added a bean post processor for the Spring Security filter chain
(so you only get traces by default if security is on)
* Every request is logged at trace level if the dump requests flag is
on
* Requests are also dumped to a TraceRepository for later analysis (very
useful for tracing problems in real time when a support call comes in)
[Fixes#48976001]
* Added a test for each of the classes loaded by the SpringApplication
* If it's an anonymous class or looks like a Groovy closure we ignore it
* The CLI sample job.groovy also modified to take advantage
[Fixes#48718891]
