Prior to this commit, every test started a new testcontainer. By splitting the
tests apart we can make use of static containers that are only instantiated once
per application (TomEE, Wildfly etc.)
See gh-25446
Move projects to better reflect the way that Spring Boot is released.
The following projects are under `spring-boot-project`:
- `spring-boot`
- `spring-boot-autoconfigure`
- `spring-boot-tools`
- `spring-boot-starters`
- `spring-boot-actuator`
- `spring-boot-actuator-autoconfigure`
- `spring-boot-test`
- `spring-boot-test-autoconfigure`
- `spring-boot-devtools`
- `spring-boot-cli`
- `spring-boot-docs`
See gh-9316
This commit reworks BootRun so that it no longer subclasses JavaExec.
This provides Boot with greater control of how the executed JVM is
configured, including the possibility of using @Option to provide args
and JVM args via the command line (gh-1176). It also allows some usage
of convention mappings to be removed in favour of PropertyState and
Provider (gh-9891). For users who relied up the advanced (and rather
complex) configuration options provided by JavaExec, an escape hatch
is provided by allowing the JavaExecSpec that's used to execute the
JVM to be customized.
Closes gh-9884
Post-processing of mocked beans causes a number of problems:
- The mock may be proxied for asynchronous processing which can cause
problems when configuring expectations on a mock (gh-6573)
- The mock may be proxied so that its return values can be cached or
so that its methods can be transactional. This causes problems with
verification of the expected calls to a mock (gh-6573, gh-5837)
- If the mock is created from a class that uses field injection, the
container will attempt to inject values into its fields. This causes
problems if the mock is being created to avoid the use of one of
those dependencies (gh-6663)
- Proxying a mocked bean can lead to a JDK proxy being created
(if proxyTargetClass=false) as the mock implements a Mockito
interface. This can then cause injection failures as the types don’t
match (gh-6405, gh-6665)
All of these problems can be avoided if a mocked bean is not
post-processed. Avoiding post-processing prevents proxies from being
created and autowiring from being performed. This commit avoids
post-processing by registering mocked beans as singletons as well as
via a bean definition. The latter is still used by the context for type
matching purposes.
Closes gh-6573, gh-6663, gh-6664
Add a `@MockBean` annotation which can be used to setup and inject mocks
into an application context. The annotation can be used on test classes,
test fields, configuration classes or configuration fields. When used on
a field the annotation also acts as an injection point.
Fixes gh-5042
Users can declare or Command, OptionHandler classes in an init script
or they can use a DSL, e.g.
command("foo") { args -> println "Do stuff with ${args} array" }
or
command("foo") {
options { option "bar", "Help text for bar option" ithOptionArg() ofType Integer }
run { options -> println "Do stuff with ${options.valueOf('bar')}" }
}
* Added CommandFactory and a ServiceLoader model for providing
implementations
* Added ScriptCommand (wrapping groovy script). Service providers
are recommended to implement OptionHandler in their script, but a
regulare Script or a Runnable will also work.
[#50427095]
izeye
dreis2211
Phillip Webb
Andy Wilkinson
Andy Wilkinson
Phillip Webb
Eddú Meléndez
Phillip Webb
Dave Syer
Dave Syer