src-spring-framework/buildSrc/README.md

# Spring Framework Build

This folder contains the custom plugins and conventions for the Spring Framework build.
They are declared in the `build.gradle` file in this folder.

## Build Conventions

### Compiler conventions

The `org.springframework.build.compile` plugin applies the Java compiler conventions to the build.

## Build Plugins

### Optional dependencies

The `org.springframework.build.optional-dependencies` plugin creates a new `optional`
Gradle configuration - it adds the dependencies to the project's compile and runtime classpath
but doesn't affect the classpath of dependent projects.
This plugin does not provide a `provided` configuration, as the native `compileOnly` and `testCompileOnly`
configurations are preferred.

### API Diff

This plugin uses the [Gradle JApiCmp](https://github.com/melix/japicmp-gradle-plugin) plugin
to generate API Diff reports for each Spring Framework module. This plugin is applied once on the root
project and creates tasks in each framework module. Unlike previous versions of this part of the build,
there is no need for checking out a specific tag. The plugin will fetch the JARs we want to compare the
current working version with. You can generate the reports for all modules or a single module:

```
./gradlew apiDiff -PbaselineVersion=5.1.0.RELEASE
./gradlew :spring-core:apiDiff -PbaselineVersion=5.1.0.RELEASE
```      

The reports are located under `build/reports/api-diff/$OLDVERSION_to_$NEWVERSION/`.
Delete obsolete TestSourcesPlugin Since we have migrated to Gradle's built-in test fixture support, the custom TestSourcesPlugin Gradle plugin is now obsolete. See gh-23550 5 years ago			`# Spring Framework Build`
Move compile config to a Gradle convention This commit moves the compile configuration from the Gradle DSL to a convention. This configuration is not changing often, and we're using that opportunity to make the Java source compatibility a project property so as to easily recent JDKs this on the command line. See gh-23282 5 years ago
			`This folder contains the custom plugins and conventions for the Spring Framework build.`
			They are declared in the `build.gradle` file in this folder.

			`## Build Conventions`

			`### Compiler conventions`

Fix typo in buildSrc/README.md See gh-24697 5 years ago			The `org.springframework.build.compile` plugin applies the Java compiler conventions to the build.
Move compile config to a Gradle convention This commit moves the compile configuration from the Gradle DSL to a convention. This configuration is not changing often, and we're using that opportunity to make the Java source compatibility a project property so as to easily recent JDKs this on the command line. See gh-23282 5 years ago
			`## Build Plugins`

Introduce Gradle Toolchain support in build 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 4 years ago			`### Optional dependencies`
Move compile config to a Gradle convention This commit moves the compile configuration from the Gradle DSL to a convention. This configuration is not changing often, and we're using that opportunity to make the Java source compatibility a project property so as to easily recent JDKs this on the command line. See gh-23282 5 years ago
			The `org.springframework.build.optional-dependencies` plugin creates a new `optional`
			`Gradle configuration - it adds the dependencies to the project's compile and runtime classpath`
			`but doesn't affect the classpath of dependent projects.`
			This plugin does not provide a `provided` configuration, as the native `compileOnly` and `testCompileOnly`
			`configurations are preferred.`

Introduce Gradle Toolchain support in build 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 4 years ago			`### API Diff`
Use JApiCmp Gradle plugin for API diffs 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 5 years ago
			`This plugin uses the [Gradle JApiCmp](https://github.com/melix/japicmp-gradle-plugin) plugin`
			`to generate API Diff reports for each Spring Framework module. This plugin is applied once on the root`
Delete obsolete TestSourcesPlugin Since we have migrated to Gradle's built-in test fixture support, the custom TestSourcesPlugin Gradle plugin is now obsolete. See gh-23550 5 years ago			`project and creates tasks in each framework module. Unlike previous versions of this part of the build,`
Use JApiCmp Gradle plugin for API diffs 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 5 years ago			`there is no need for checking out a specific tag. The plugin will fetch the JARs we want to compare the`
			`current working version with. You can generate the reports for all modules or a single module:`

			```
			`./gradlew apiDiff -PbaselineVersion=5.1.0.RELEASE`
			`./gradlew :spring-core:apiDiff -PbaselineVersion=5.1.0.RELEASE`
			```

Delete obsolete TestSourcesPlugin Since we have migrated to Gradle's built-in test fixture support, the custom TestSourcesPlugin Gradle plugin is now obsolete. See gh-23550 5 years ago			The reports are located under `build/reports/api-diff/$OLDVERSION_to_$NEWVERSION/`.