Spring Framework
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

56 lines
1.4 KiB

plugins {
id "com.gradle.enterprise" version "3.14"
id "io.spring.ge.conventions" version "0.0.13"
id "org.gradle.toolchains.foojay-resolver-convention" version "0.7.0"
}
include "spring-aop"
include "spring-aspects"
include "spring-beans"
include "spring-context"
Support for candidate components index This commit adds a "spring-context-indexer" module that can be added to any project in order to generate an index of candidate components defined in the project. `CandidateComponentsIndexer` is a standard annotation processor that looks for source files with target annotations (typically `@Component`) and references them in a `META-INF/spring.components` generated file. Each entry in the index is the fully qualified name of a candidate component and the comma-separated list of stereotypes that apply to that candidate. A typical example of a stereotype is `@Component`. If a project has a `com.example.FooService` annotated with `@Component` the following `META-INF/spring.components` file is generated at compile time: ``` com.example.FooService=org.springframework.stereotype.Component ``` A new `@Indexed` annotation can be added on any annotation to instructs the scanner to include a source file that contains that annotation. For instance, `@Component` is meta-annotated with `@Indexed` now and adding `@Indexed` to more annotation types will transparently improve the index with additional information. This also works for interaces or parent classes: adding `@Indexed` on a `Repository` base interface means that the indexed can be queried for its implementation by using the fully qualified name of the `Repository` interface. The indexer also adds any class or interface that has a type-level annotation from the `javax` package. This includes obviously JPA (`@Entity` and related) but also CDI (`@Named`, `@ManagedBean`) and servlet annotations (i.e. `@WebFilter`). These are meant to handle cases where a component needs to identify candidates and use classpath scanning currently. If a `package-info.java` file exists, the package is registered using a "package-info" stereotype. Such files can later be reused by the `ApplicationContext` to avoid using component scan. A global `CandidateComponentsIndex` can be easily loaded from the current classpath using `CandidateComponentsIndexLoader`. The core framework uses such infrastructure in two areas: to retrieve the candidate `@Component`s and to build a default `PersistenceUnitInfo`. Rather than scanning the classpath and using ASM to identify candidates, the index is used if present. As long as the include filters refer to an annotation that is directly annotated with `@Indexed` or an assignable type that is directly annotated with `@Indexed`, the index can be used since a dedicated entry wil be present for that type. If any other unsupported include filter is specified, we fallback on classpath scanning. In case the index is incomplete or cannot be used, The `spring.index.ignore` system property can be set to `true` or, alternatively, in a "spring.properties" at the root of the classpath. Issue: SPR-11890
8 years ago
include "spring-context-indexer"
include "spring-context-support"
include "spring-core"
include "spring-core-test"
include "spring-expression"
include "spring-instrument"
include "spring-jcl"
include "spring-jdbc"
include "spring-jms"
include "spring-messaging"
include "spring-orm"
include "spring-oxm"
include "spring-r2dbc"
include "spring-test"
include "spring-tx"
include "spring-web"
include "spring-webflux"
include "spring-webmvc"
include "spring-websocket"
Stop publishing distribution zip artifact Prior to this commit, the Spring Framework build would publish several zip artifacts: * a "*-schema.zip" containing all the XSD schemas produced * a "*-docs.zip" containing the API docs * a "*-dist.zip" containing all of the above, plus module jars Since the reference docs are now produced by Antora in a separate process, the "*-docs.zip" does not contain the reference docs anymore. But it still contains the API docs which are automatically fetched from the artifact repository and published on the docs.spring.io website. This commit intends to update the current arrangement and optimize the build. First, the "*-dist.zip" is not published anymore, since it cannot be consumed anyway by the community: repo.spring.io does not distribute release artifacts publicly, developers are expected to get them from Maven Central. This arrangement is quite dated anyway and is not really useful in current application build setups. The generation of API docs is moved to a new "framework-api" module, separating it from the reference docs module ("framework-docs") which contains Java, Kotlin and Asciidoctor sources. This removes the custom javadoc aggregation task and instead uses a dedicated Gradle plugin. This change also adds a new `-PskipDocs` Gradle project property that skips entirely the documentation tasks (javadoc, kdocs) as well as the "distrbution" tasks managed in the framework-api module. This allows developers to publish locally a SNAPSHOT of Spring Framework without creating the entire documentation distribution. This is particularly useful for local testing. For example, `$ ./gradlew pTML -PskipDocs`. Closes gh-31049
1 year ago
include "framework-api"
include "framework-bom"
include "framework-docs"
include "framework-platform"
include "integration-tests"
rootProject.name = "spring"
rootProject.children.each {project ->
project.buildFileName = "${project.name}.gradle"
}
settings.gradle.projectsLoaded {
gradleEnterprise {
buildScan {
File buildDir = settings.gradle.rootProject
.getLayout().getBuildDirectory().getAsFile().get()
buildDir.mkdirs()
new File(buildDir, "build-scan-uri.txt").text = "(build scan not generated)"
buildScanPublished { scan ->
if (buildDir.exists()) {
new File(buildDir, "build-scan-uri.txt").text = "${scan.buildScanUri}\n"
}
}
}
}
}