Previously, the .class file for the renamed properties class was
on the class path of the compilation in two places:
1. The output directory of the test's previous compilation
2. The output directory of the compilation of src/test/java of
spring-boot-configuration-processor
The first of these locations is addressed by updating TestProject.
The .class file is now deleted from the project's output location
at the same time as the .java file is deleted from its source
location.
The second of these locations is addressed by configuring the class
path of the compiler to include a copy of the result of compiling
src/test/java of spring-boot-configuration-processor. From this copy
entries can then be deleted as needed without destabilizing other tests.
Closes gh-26271
Update `ModifiedClassPathExtension` and related classes so that
annotations can be used directly on test methods, or on classes
passed into parameterized tests.
Closes gh-33014
Update `Log4J2LoggingSystemTests` to exclude Logback and include
'log4j-slf4j-impl'. The `ModifiedClassPathClassLoader` has also been
updated so that it no longer automatically excludes `log4j` artifacts,
instead we now use `@ClassPathExclusions` on the relevant tests.
Fixes gh-19365
- Adds a new @DisableOnOs annotation, which is inspired from JUnit5s
@DisableOnOs annotation. This new annotation supports the architecture
and is repeatable
Closes gh-30082
A new system test plugin is being made available for running test
suites that should be run less frequently than with every commit, such
as tests that verify Spring Boot compatibility with external
projects. CI pipeline configuration for running system tests is also
provided.
The first system tests verify the behavior of the Spring Boot image
building plugins when building images using Paketo buildpacks.
Closes gh-25824
In our tests, the JNI code in Netty tcNative can cause some of its
classes to be loaded using a ModifiedClassPathClassLoader. When the
wrong class loader is used, SSL-related tests fail, for example due
to the same Netty tcNative classes being loaded by two different
ClassLoders and no longer being the same. This appears to be
dependent upon the order in which tests are executed and results in
intermittent test failures.
It looks like this should be addressed in Netty tcNative 2.0.40 which
preloads all of its classes. In the meantime, this commit updates
ModifiedClassPathClassLodaer to ignore Netty tcNative classes so that
they're only ever loaded by the system class loader.
Closes gh-26749