The use of LinkedCaseInsensitiveMap, going back to 3.0, makes it
unnecessary to iterate over keys which can cause
ConcurrentModificationException.
Closes gh-23460
Previously DefaultWebClientBuilder always defaulted the ClientHttpConnector
with ReactorClientHttpConnector. This worked fine if reactor was used.
However, it would break if the user was trying to leverage Jetty.
This commit defaults to use Reactory Netty HttpClient if it is present. If
it is not present it then Jetty's HttpClient is used if present.
Closes gh-23491
Prior to this commit, the reference documentation build with asciidoctor
would get the common "spring-docs-resources" as a dependency and then
use it when generating the docs.
As seen in #23124, this can cause problems since we'd like to
consistently resolve our dependencies. In this case, the
"spring-doc-resources" archive is not published on maven central since
it's not officially supported by the Spring team as an open source
project.
This commit updates the reference documentation build to get this
archive as a simple download task and avoid resolving it as a
dependency.
See gh-23282
This commit ensures that the spring-framework-bom project is ignored
from the global configuration block. If not, many conventions and
dependencies are added to it and add noise to the published BOM.
See gh-23282
This commit reorganizes tasks and scripts in the build to only apply
them where they're needed. We're considering here 3 "types" of projects
in our build:
* the root project, handling documentation, publishing, etc
* framework modules (a project that's published as a spring artifact)
* internal modules, such as the BOM, our coroutines support and our
integration-tests
With this change, we're strealining the project configuration for all
spring modules and only applying plugins when needed (typically our
kotlin support).
See gh-23282
Due to a bug (or "unintentional feature") in JUnit 4, overridden test
methods not annotated with @Test are still executed as test methods;
however, JUnit Jupiter does not support that. Thus, prior to this
commit, some overridden test methods in spring-core were no longer
executed after the migration from JUnit 4 to JUnit Jupiter.
This commit addresses this issue for such known use cases, but there
are likely other such use cases within Spring's test suite.
See gh-23451
The recently added body(Object) variant can be confused easily with
body(Publisher, Class) forgetting to provide the element type and
only running into the IllegalArgumentException at runtime.
See gh-23212
This commit moves the dependency management and test source files
related to integration tests to a dedicated module.
This allows us to focus the root project on building the Spring
Framework.
See gh-23282
This commit removes JDiff from the Spring Framework build and instead,
adds a Gradle plugin that configure JApiCmp tasks on the framework
modules.
Fixes gh-22942
See gh-23282
Add `SpringJUnit5` checkstyle rule to ensure that JUnit 4 annotations
aren't accidentally used in new tests.
The "must not be public" rule has been suppressed since there are
quite a few tests that extend base tests from other packages.
This commit migrates the spring-test test suite from JUnit 4 to JUnit
Jupiter where applicable.
Tests specific to our JUnit 4 and TestNG support remain written using
those frameworks. In addition, some tests are still written in JUnit 4
if they extend a test class that should not be migrated to JUnit
Jupiter.
See gh-23451
This commit removes the JUnit 4 dependency from all modules except
spring-test which provides explicit JUnit 4 support.
This commit also includes the following.
- migration from JUnit 4 assertions to JUnit Jupiter assertions in all
Kotlin tests
- migration from JUnit 4 assumptions in Spring's TestGroup support to
JUnit Jupiter assumptions, based on org.opentest4j.TestAbortedException
- introduction of a new TestGroups utility class than can be used from
existing JUnit 4 tests in the spring-test module in order to perform
assumptions using JUnit 4's Assume class
See gh-23451
This commit migrates parameterized tests in spring-core using the
"composed @ParameterizedTest" approach. This approach is reused in
follow-up commits for the migration of the remaining modules.
For a concrete example, see AbstractDataBufferAllocatingTests and its
subclasses (e.g., DataBufferTests).
Specifically, AbstractDataBufferAllocatingTests declares a custom
@ParameterizedDataBufferAllocatingTest annotation that is
meta-annotated with @ParameterizedTest and
@MethodSource("org.springframework.core.io.buffer.AbstractDataBufferAllocatingTests#dataBufferFactories()").
Individual methods in concrete subclasses are then annotated with
@ParameterizedDataBufferAllocatingTest instead of @ParameterizedTest or
@Test.
The approach makes the migration from JUnit 4 to JUnit Jupiter rather
straightforward; however, there is one major downside. The arguments
for a @ParameterizedTest test method can only be accessed by the test
method itself. It is not possible to access them in an @BeforeEach
method (see https://github.com/junit-team/junit5/issues/944).
Consequently, we are forced to declare the parameters in each such
method and delegate to a custom "setup" method. Although this is a bit
cumbersome, I feel it is currently the best way to achieve fine grained
parameterized tests within our test suite without implementing a custom
TestTemplateInvocationContextProvider for each specific use case.
Once https://github.com/junit-team/junit5/issues/878 is resolved, we
should consider migrating to parameterized test classes.
See gh-23451
Rossen Stoyanchev
Rob Winch
Brian Clozel
Sam Brannen
Stephane Nicoll
Sebastien Deleuze
부종민
Phillip Webb
Andrey Kolchanov