Reorganize Gradle build #23282
Comments
We need to be cautious here. Buildship is not perfect, and the last time I checked... we need our custom configuration for the Eclipse classpath, etc. Maybe you can perform that work in a dedicated PR for closer review? |
|
@sbrannen We don't use that support in our own documentation for contributors: https://github.com/spring-projects/spring-framework/blob/master/import-into-eclipse.md I thought it wasn't relevant anymore? |
|
@bclozel, whenever one uses Buildship in Eclipse, the I don't think it's well documented, but it is at least officially mentioned here and here. And the "Project synchronization" section of this article demonstrates advanced features like those that we use in In summary, if we remove all of our |
This commit moves the existing "test sources" Gradle plugin from Groovy to Java and updates the "buildSrc" build file to prepare for additional plugins in the Spring Framework build. The plugin itself looks, for a given Spring Framework module, at all the project dependencies for the following scopes: "compile", "testCompile", "api", "implementation" and "optional" (to be supported by a different plugin). See gh-23282
Prior to this commit, the Spring Framework build would be using the propdeps Gradle plugin to introduce two new configurations to the build: "optional" and "provided". This would also configure related conventions for IDEs, adding those configurations to published POMs. This commit removes the need for this plugin and creates instead a custom plugin for an "optional" configuration. While the Eclipse IDE support is still supported, there is no need for specific conventions for IntelliJ IDEA anymore. This new plugin does not introduce the "provided" scope, as "compileOnly" and "testCompileOnly" are here for that. Also as of this commit, optional/provided dependencies are not published with the Spring Framework modules POMs annymore. Generally, these dependencies do not provide actionable information to the developers reading / tools consuming the published POMs. Optional/Provided dependencies are **not**: * dependencies you can add to enable some supported feature * dependencies versions that you can use to figure out CVEs or bugs * dependencies that might be missing in existing Spring applications In the context of Spring Framework, optional dependencies are just libraries are Spring is compiling against for various technical reasons. With that in mind, we are not publishing that information anymore. See gh-23282
|
@bclozel Is there a reason we want to remove the provided/optional dependencies? As a consumer of projects, I find it useful to look in the pom to see what version of optional dependencies they use so I know which versions are going to work. Granted I could look in the Gradle build for this information, but Gradle's flexibility in this manner makes it harder to figure out than looking in a pom.xml file. |
|
@bclozel Thanks for the additional information. I don't agree with the assessment. Even if things are easier to read by moving them to the main build.gradle, this is something specific to Spring Framework's Gradle build. This simplification still requires knowledge of Gradle and Spring Frameworks build (other projects could just as easily place the information in the build.gradle for each project). This means a Maven user must have knowledge of Gradle in order to figure out the optional dependencies. User's could look at Spring Boot for guidance on dependencies, but this is also confusing. I've never been told to look for dependencies I should use by leveraging a separate project. How is a user to know that they should look at Spring Boot for the dependencies? Spring Boot can help with versions, but how does it indicate what groupId/artifactId users should be using for each Spring project? I understand that mapping in Maven is far from perfect. However, defining optional and provided dependencies is what is expected in Maven pom.xml files. Deviating from this convention in a Maven pom.xml is confusing to Maven users even if it is not a direct mapping from our Gradle build. Asking Maven users to learn another build system or look in another project for dependency information is not ideal either (it deviates from Maven definition of a pom.xml). Please consider adding optional and provided dependencies back to Spring's pom.xml. |
|
@rwinch my last assessment was only directed to you, when looking for information about the Spring Framework build as a project maintainer. I think there are two issues here:
In the end, removing that information from the generated POM is more about avoiding to communicate misleading information. The Spring Boot BOM fills that role in a much better way: it provides information about dependencies (coordinates, version) that are fully tested by the Spring Boot build with many Spring projects. This BOM can be used by non-Spring Boot applications as well. I for some reason we don't want to involve Spring Boot here, we should provide this information in a different way and not try to derive it from our build since it seems we can't extract meaningful information from it for this use case. |
|
The problem with these approaches is that it deviates from Maven's definition of a pom.xml and yet we are publishing a Maven pom.xml Deviating from the Maven definition of a pom is even more confusing (because we are trying to define it ourselves). The confusion around what the optional / provided mean is expected in a Maven pom and developers using Maven have become accustom to that. If we are going to publish a pom, it should follow Maven conventions which include provided and optional dependencies. |
|
We're still publishing a perfectly valid POM, and generating that information from our Gradle build. We do have many custom and non-custom configurations, including Even in a pure Maven setup, you can filter/flatten your published POMs, and I'd argue we're doing that now to avoid misleading our users. Unless we find a way to provide accurate and meaningful information in our metadata, I don't see a good reason to bring that back into the published POM. Let's take a step back. What are the use cases for getting the information we were providing so far and why? |
As a user of pom.xml this is where I know to go to get dependency information. Putting the information anywhere else puts Spring on an island which means extra work for users to discover where that information is. I believe all comments about why we don't want to do it because it is confusing is something that is expected in Maven projects. Removing the information is not helpful because it is different than what users are expecting. A few responses to the examples:
I don't understand why this is a problem. User's aren't going to bring the dependencies in if they don't need them. They are optional/provided...so a user isn't going to add them.
Correct, but the information for reactor-netty is in the pom which they do need information about. If the dependency is listed as optional or provided users are use to sorting through this.
This is something that users are use to. Place the best version as an optional dependency to convey what is preferred but don't remove the information all together. This is not any different than a required dependency where multiple versions are supported. Boot takes a preference for JUnit 4 and provides this in the pom, but JUnit 5 is still supported. |
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
This commit removes unused parts of the Gradle build: * Gradle wrapper customization which should not be needed in recent versions of Gradle (or can be replaced with options in the gradle.properties file) * the branch strategy configuration See gh-23282
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 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
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
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
Prior to this commit, the Spring Framework build would mix proper framework modules (spring-* modules published to maven central) and internal modules such as: * "spring-framework-bom" (which publishes the Framework BOM with all modules) * "spring-core-coroutines" which is an internal modules for Kotlin compilation only This commit renames these modules so that they don't start with "spring-*"; we're also moving the "kotlin-coroutines" module under "spring-core", since it's merged in the resulting JAR. See gh-23282
This commit configures the Gradle Download plugin that's used a build step when generating the reference documentation. Here we're making sure that the task is caching and reusing the resource if it's been downloaded already. See gh-23282
Prior to this commit, the build would use a custom task to create a BOM and manually include/exclude/customize dependencies. It would also use the "maven" plugin to customize the POM before publication. This commit now uses a Gradle Java Platform for publishing the Spring Framework BOM. We're also now using the "maven-publish" plugin to prepare and customize publications. This commit also tells the artifactory plugin (which is currently applied only on the CI) not to publish internal modules. See gh-23282
This commit switches to the default publication name considered by the artifactory plugin when it comes to publishing artifacts to the artifactory repository. See gh-23282
Instead of relying on the CI server to apply and configure this plugin, this commit does it directly in the Spring Framework build. This allows us to take full control over which projects are published and how. See gh-23282
This commit ensures that Gradle publications are using resolved dependency versions for Maven publications (i.e. POMs). This is useful since we're using the Spring dependency management plugin and we can't rely on declared dependency versions only. See gh-23282
|
Our Gradle build has been significantly refactored and published artifacts are stable. |
|
Related to #23550 |
This is a much needed follow up issue for #20440.
Currently the Spring Framework build is mixing scripts, conventions and dependency information in
.gradlefiles, some of them externalized in a gradle folder. The goal of this issue is to refactor the current build to scripts and conventions into build plugins. Each project/subproject should then selectively apply those plugins and only describe the specific dependencies in their build file.Since our last efforts, Gradle had significant improvements and lots of new features that could be useful to Spring Framework.
Here is the list of the tasks for this issue:
provided/optionalwithcompileOnlyand a customoptionalconfiguration (see spring-core-5.2.0.M3.pom missing netty dependencies #23234)libs-*repo in favour of consistent use of Maven Central #23124)"spring-*"as a project name only for Spring Framework published modules. Rename internal modules accordingly ("spring-framework-bom", "spring-core-coroutines"...)The text was updated successfully, but these errors were encountered: