This commit polishes 85d4a79 so that the target type of factory bean
is only considered if the FactoryBean is accessible. If the FactoryBean
requires protected access, we still generate the code in the package of
the FactoryBean.
Those two commits combined are actually providing a fix for the use
case described in gh-28809.
Closes gh-28809
This commit improves the location of generated bean definitions for
FactoryBean implementations by checking the type that the factory
bean generates, rather than the factory bean implementation itself.
Closes gh-28812
Migrate all AOT tests to make use of `GeneratedClasses` rather than
directly generating Java files. This commit also refines and polishes
AOT APIs to being greater consistency.
Specifically:
- The `MethodGenerator` interface has been removed in favor of
working directly with `GeneratedMethods`.
- The visibility of several constructors and methods has been
reduced to package-private.
- The `using(...)` and `builder` methods have been removed in
favor of setting the `Consumer` callbacks directly as
constructor arguments.
- Variable names for builders are now named `type` or `method`
depending on what they're building.
Closes gh-28831
- remove not-empty precondition check for packageNames so that the core
scan() method can actually be used.
- document constructor
- document use case for packageNames
- add test that scan's all test classes in the spring-test project
- reduce logging due to the previous action item
See gh-28824
The search algorithm for @ExtendWith should not be tied to Spring's
@NestedTestConfiguration semantics. Rather, general JUnit annotation
search semantics should be used to find @ExtendWith.
See gh-28824
Since the RuntimeHintsAgentCondition is based solely on the result of
invoking a boolean static method, there is no need to implement a custom
ExecutionCondition. For such use cases, the @EnabledIf support in JUnit
Jupiter is sufficient.
This commit therefore replaces the custom RuntimeHintsAgentCondition
with use of @EnabledIf as a meta-annotation.
Commit d1b65f6d3e introduced a regression regarding the handling of
missing dependencies for optional (typically default)
TestExecutionListeners.
Prior to d1b65f6d3e a TestExecutionListener was instantiated using
java.lang.Class.newInstance() which never throws an
InvocationTargetException. With the switch to the new
SpringFactoriesLoader APIs, a TestExecutionListener is now instantiated
using java.lang.reflect.Constructor.newInstance(Object...) which can
throw an InvocationTargetException.
This commit addresses the regression by unwrapping the target exception
in an InvocationTargetException.
See gh-28666
Closes gh-28828
This commit introduces the TestClassScanner which scans provided
classpath roots for Spring integration test classes using the JUnit
Platform Launcher API which allows all registered TestEngines to
discover tests according to their own rules.
The scanner currently detects the following categories of Spring
integration test classes.
- JUnit Jupiter: classes that register the SpringExtension via
@ExtendWith.
- JUnit 4: classes that register the SpringJUnit4ClassRunner or
SpringRunner via @RunWith.
- Generic: classes that are annotated with @ContextConfiguration or
@BootstrapWith.
The scanner has been tested with the following TestEngine
implementations for the JUnit Platform.
- JUnit Jupiter
- JUnit Vintage
- JUnit Platform Suite Engine
- TestNG Engine for the JUnit Platform
Closes gh-28824
Stephane Nicoll
Phillip Webb
Olga Maciaszek-Sharma
Adrian Bob
Sébastien Deleuze
Jupiter
Sam Brannen
Brian Clozel
Arjen Poutsma
rstoyanchev
Spring Builds
Juergen Hoeller
Marc Wrobel