- Switch to Caffeine for caching since it is supported on native unlike Ehcache
- Use latest metadata repository 0.2.3 (will be the default with Native Build Tools 0.9.15)
- Registers resource hints for WebJars and db resource directory
In order to improve efficiency (see spring-projects/spring-framework#27619)
and allow native image compatibility, this commit uses WebJars versioned URLs
which are supported out of the box on Spring Boot via /META-INF/resources
default resource location configuration, removing the need to use
webjars-locator-core dependency and WebJarsResourceResolver.
I have been able to measure a consistent 5% startup time improvement on
the JVM with that simple change on my local machine.
Open session in view was switched off accidentally a while ago. Also
the mapping changes recently meant that the changes to @Valid model
attributes were not being propagated correctly.
Fixes#946 and #947
As part of a process to build a BOSH release, I encountered the error
below while running `./mvnw package`:
```
[ERROR] Failed to execute goal pl.project13.maven:git-commit-id-plugin:3.0.1:revision (default) on project spring-petclinic: Could not complete Mojo execution...: Error: Could not get HEAD Ref, are you sure you have set the dotGitDirectory property of this plugin to a valid path? -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
```
That's because we are just interested on the source files for the BOSH
release, we don't care about repo metadata (so we exclude them).
Going through the [git-commit-id-maven-plugin
docs](https://github.com/git-commit-id/git-commit-id-maven-plugin/blob/master/maven/docs/using-the-plugin.md)
we learned it is possible to prevent the failure above via
configuration.
We propose then to set
`<failOnUnableToExtractRepoInfo>false</failOnUnableToExtractRepoInfo>`,
enabling use cases similar to ours.
FWIW `failOnNoGitDirectory` is already set to false.
