This commit uses standard files for libraries managed by the repackage
goal of the Maven plugin. Previously, only the name of the file was used
which could lead to duplicate libraries if the name of the target file
deviates from the default. This typically happens when the
`build.finalName` property is specified on a dependent module.
Note that the `maven-war-plugin` has an additional mechanism to customize
the file name structure of dependencies. This feature isn't supported by
the repackage goal so an explicit mention has been added in the
documentation.
Closes gh-7389
Previously, if `spring.couchbase.bootstrap-hosts` was specified in YAML
or with the `[Idx]` notation, the auto-configuration would not kick in.
This is due to a limitation of `@ConditionalOnProperty` on a property of
type Collection. This commit workarounds this limitation for now with a
dedicated condition.
Closes gh-7508
This commit promotes the plugin dependency management for the
`maven-enforcer-plugin` and `maven-invoker-plugin` to the root. That way
these can be used in samples as well rather than having a separate copy.
Closes gh-7517
Allow support for custom Lyout implementations with both the Maven
and Gradle plugin. Implementations of `LayoutFactory` can now be
specified to allow customization of the layout. In addition a
layout may now implement `CustomLoaderLayout` if it wishes to
write custom loader classes.
See gh-7263
Checking for the presence of a `ValidationProvider` resource is
unfortunately not enough to trigger the validation auto-configuration.
If `hibernate-validator` is added on the classpath without a `javax.el`
implementation, the former will blow up on startup. So far this was a
pilot error so we didn't have to care about it. Now that we have an
auto-configuration that may lead to this error, we need to be extra
careful and check that scenario ourselves.
This commit adds an extra condition that runs as late as possible and
attempt to actually initialize a `Validator`. If that fails for whatever
reason, the auto-configuration will now back off.
Several additional tests have been added to exercise this scenario.
Closes gh-6228
Previously, ResetMocksTestExecutionListener used getBean(name) to
retrieve each instantiated singleton. When the instantiated singleton
was a factory bean, this would cause getObject on the factory bean to
be called. If the factory bean was unable to produce its object, for
example due to test slicing excluding something, an exception would
be thrown.
The previous commit updated ResetMocksTestsExecutionListener to
use getSingleton(name) rather than getBean(name). This will retrieve
the factory bean itself rather than causing the factory bean to
attempt to create an object. This commit updates the tests to verify
the new behaviour.
Closes gh-7270
Stephane Nicoll
Johnny Lim
Oscar Utbult
Andy Wilkinson
Hrishikesh Joshi
Phillip Webb
Dave Syer
Aleksander Bartnikiewicz