Prior to this commit, support was provided for disabling cron jobs
configured with an explicit "-" cron expression. However, the "-"
expression was only supported when supplied via the @Scheduled
annotation.
This commit adds support for disabling cron jobs configured with the
"-" cron expression when a cron job is registered via the
addCronTask(Runnable, String) method in the ScheduledTaskRegistrar
supplied to a SchedulingConfigurer.
Closes gh-23568
As a follow-up of gh-22915, the purpose of this commit is to improve
Coroutines programmatic transaction API to make it more consistent with
the Java one and more idiomatic.
For suspending functions, this commit changes the
TransactionalOperator.transactional extension with a suspending lambda
parameter to a TransactionalOperator.executeAndAwait one which is
conceptually closer to TransactionalOperator.execute Java API so more
consistent.
For Flow, the TransactionalOperator.transactional extension is correct
but would be more idiomatic as a Flow extension.
This commit also adds code samples to the reference documentation.
Closes gh-23627
Prior to this commit, the copyConfigurationFrom(ConfigurableBeanFactory)
method in DefaultListableBeanFactory cloned its own AutowireCandidateResolver
type instead of the resolver type from the supplied ConfigurableBeanFactory.
This commit fixes that by cloning the resolver type from the supplied
ConfigurableBeanFactory.
Closes gh-23569
Previously, some tests in spring-context wrote a file named jmx.log
into spring-context/. This led to the file being included in the
sources of the Checkstyle NoHTTP Gradle task, breaking that task's
UP-TO-DATE checks and causing it to execute unnecessarily.
This commit updates the tests to write the jmx.log file beneath
spring-context/build/ so that it is not included in the sources of the
Checkstyle NoHTTP task.
Closes gh-23623
Prior to this commit, a lot of work had been done to prevent improper
use of testing Framework APIs throughout the codebase; however, there
were still some loopholes.
This commit addresses these loopholes by introducing additional
Checkstyle rules (and modifying existing rules) to prevent improper use
of testing framework APIs in production code as well as in test code.
- Checkstyle rules for banned imports have been refactored into
multiple rules specific to JUnit 3, JUnit 4, JUnit Jupiter, and
TestNG.
- Accidental usage of org.junit.Assume has been switched to
org.junit.jupiter.api.Assumptions.
- All test classes now reside under org.springframework packages.
- All test classes (including abstract test classes) now conform to the
`*Tests` naming convention.
- As an added bonus, tests in the renamed
ScenariosForSpringSecurityExpressionTests are now included in the
build.
- Dead JUnit 4 parameterized code has been removed from
DefaultServerWebExchangeCheckNotModifiedTests.
Closes gh-22962
Previously, all tasks in the build were run sequentially. This
commit updates Gradle's properties to build them in parallel where
possible. When using the daemon (recommended) its default max heap is
not sufficient for the demands on a parallel build, therefore this
commit also increases the daemon's max heap.
See gh-23620
This commit renames Spr3896SuiteTests to comply with our naming
convention for test classes that should be executed via the Gradle
build.
The effect of this commit is that test classes included in that "suite"
are no longer executed twice in the build. Consequently, Gradle and
Bamboo will now report the same number of executed tests for the
spring-test project.
Previously, changing modules (snapshots) and dynamic versions were
cached for Gradle's default period of 24 hours and
--refresh-dependencies was used to pick up the latest artifacts. This
approach has a notable downside. --refresh-dependencies causes all
dependencies to be refreshed, irrespective of whether they are
expected to change. At a minimum, this results in a HEAD request for
every dependency in the build. Running an up-to-date build without
--refresh-dependencies takes in the region of 6 seconds:
$ ./gradlew build
BUILD SUCCESSFUL in 6s
203 actionable tasks: 203 up-to-date
The same build with --refresh-dependencies takes almost ten times as
long:
$ ./gradlew build --refresh-dependencies
BUILD SUCCESSFUL in 58s
203 actionable tasks: 203 up-to-date
This commit replaces the manual usage of --refresh-dependencies on
the command line with a 0 second caching period for changing modules
and dynamic versions. This should remove the need to use
--refresh-dependencies both locally and on CI, saving almost 1 minute
per full build.
Prior to this commit, Spring failed to determine that an XML config file
was DTD-based if the DTD declaration was followed by a comment.
This commit fixes this by modifying the consumeCommentTokens(String)
algorithm in XmlValidationModeDetector so that both leading and trailing
comments are properly consumed without losing any XML content.
Closes gh-23605
Since it does not appear that JUnit 4.13 will be released before Spring
Framework 5.2 GA, I am reverting back to JUnit 4.12 for the time being.
See gh-22894
When exposed as an environment variable Bamboo's bamboo.resultsUrl
is mapped to bamboo_resultsUrl. This commit updates the build scan
user data script to look for the latter rather than the former.
Closes gh-23597
When exposed as an environment variable Bamboo's bamboo.resultsUrl
is mapped to bamboo_resultsUrl. This commit updates the build scan
user data script to look for the latter rather than the former.
When exposed as an environment variable Bamboo's bamboo.resultsUrl
is mapped to bamboo_resultsUrl. This commit updates the build scan
user data script to look for the latter rather than the former.
This commit adds opt-in build scan integration with Gradle Enterprise.
When the GRADLE_ENTERPRISE_URL environment variable is set on a
developer's machine or on CI, a build scan will be automatically
uploaded to Gradle Enterprise at the end of the build.
This initial integration will establish a baseline for Spring
Framework builds. Once that baseline has been established we can use
the build scans to identify ways in which the build can be optimized
and updated to make use of Gradle's build caching which should reduce
build times, significantly so for changes that only affect tasks near
the leaf nodes of the task graph.
