The dependency on spring-web from spring-beans makes it impossible to
import the projects in Eclipse IDE due to cycles between projects.
This commit therefore moves the web-related test for
BeanUtilsRuntimeHints to spring-web.
See gh-30491
Prior to this commit, GroovyDynamicElementReader was implemented in
Groovy, which required that developers have Groovy language support
installed and configured in their IDEs.
This commit ports GroovyDynamicElementReader from Groovy to Java,
making the compilation much simpler and allowing developers to open the
project in Eclipse or VSCode (or other IDEs without Groovy support)
without compiler errors.
This commit also converts related tests from Groovy to Java.
Closes gh-27945
This commit partially reverts cf2429b0f0
in order to reinstate -Werror for Groovy compilation in spring-beans.
The `decorating` field in GroovyDynamicElementReader has been changed
from boolean to Boolean in order to avoid the JDK 17 deprecation warning
for use of `new Boolean(false)` which the Groovy compiler apparently
uses behind the scenes when compiling Groovy source code.
Includes hard JDK 9+ API dependency in CGLIB ReflectUtils (Lookup.defineClass) and removal of OutputStream spy proxy usage (avoiding invalid Mockito proxy on JDK 17)
Closes gh-26901
Prior to this commit, the Spring Framework build would rely on
setting a custom Java HOME for building all sources and tests
with that JDK.
This approach is not flexible enough, since we would be testing
the source compatibility against a recent JDK, but not a common
case experienced by the community: compiling and running
application code with a recent JDK and the official, JDK8-based
Framework artifacts.
This method is also limiting our choice of JDKs to the ones
currently supported by Gradle itself.
This commit introduces the support of Gradle JVM Toolchains in
the Spring Framework build.
We can now select a specific JDK for compiling the main
SourceSets (Java, Groovy and Kotlin) and another one for
compiling and running the test SourceSets:
`./gradlew check -PmainToolChain=8 -PtestToolchain=15`
Gradle will automatically find the JDKs present on the host or
download one automcatically. You can find out about the ones
installed on your host using:
`./gradlew -q javaToolchains`
Finally, this commit also refactors the CI infrastructure to:
* only have a single CI image (with all the supported JDKs)
* use this new feature to compile with JDK8 but test it
against JDK11 and JDK15.
Closes gh-25787
- Build Scan plugin is now Gradle Enterprise plugin applied in settings
- Compile task dependencies are now defined through classpath
- Test fixture publication can be disabled through public API
Closes gh-24384
Prior to this commit, the Spring Framework build would partially use the
dependency management plugin to import and enforce BOMs.
This commit applies the dependency management plugin to all Java
projects and regroups all version management declaration in the root
`build.gradle` file (versions and exclusions).
Some versions are overridden in specific modules for
backwards-compatibility reasons or extended support.
This commit also adds the Gradle versions plugin that checks for
dependency upgrades in artifact repositories and produces a report; you
can use the following:
./gradlew dependencyUpdates
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
After the Groovy 2.5 upgrade, the Spring Framework build on JDK9 hit
GROOVY-8631. Adding the relevant `jax-api` dependency to the module
didn't fix this issue. The Groovy release notes mention the use of the
`--add-modules` JVM flag, but this is not an option for this build which
should run on JDK8 -> JDK11.
This commit changes the dependency from `groovy-all` to more focused
dependencies on Groovy in the `spring-beans` and `spring-context`
modules. This change seems to avoid the automatic loading of Groovy
enhancements to JAXB (shipped with `groovy-xml`).
See:
* http://groovy-lang.org/releasenotes/groovy-2.5.html#Groovy2.5releasenotes-Knownissues
* https://issues.apache.org/jira/browse/GROOVY-8631
Issue: SPR-15407
This commit merges back the "spring-beans-groovy" module into the main
"spring-beans" one. The build is configured so:
* Java and Groovy sources are jointly compiled
* Kotlin sources are compiled after
With this change, the `MergePlugin` is not used anymore in the project
build and therefore is removed.
The `DetectSplitPackagesPlugin` wasn't applied so it's been removed as
well.
Issue: SPR-15885
Juergen Hoeller
Sébastien Deleuze
Sam Brannen
Stephane Nicoll
Dave Syer
Sam Brannen
Brian Clozel
Jendrik Johannes
Sam Brannen
Juergen Hoeller
Brian Clozel
Stephane Nicoll
Sebastien Deleuze
Thor Andreas Rognan