Reorganize Gradle build

[bclozel]

This is a much needed follow up issue for #20440.

Currently the Spring Framework build is mixing scripts, conventions and dependency information in .gradle files, 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:

• Rewrite the "test source sets" plugin from Groovy to Java
• Do not use the propdeps plugin and replace provided/optional with compileOnly and a custom optional configuration (see spring-core-5.2.0.M3.pom missing netty dependencies #23234)
• Do not publish optional/provided dependencies in published POMs
• Move the Java compilation configuration to a convention. The Kotlin one is short and comes with the Kotlin plugin declaration, so we're letting that part in the main build file for now.
• Remove Gradle wrapper customization as script and move it to gradle.properties if necessary
• Move the JDiff to a separate plugin and use Japicmp instead
• Move integration tests to a separate module
• Reorganize tasks and scripts to selectively apply them to one of: root project, framework module, internal module (BOM, coroutines, integration-tests)
• Download the "spring-docs-resources" zip as an URL and do not resolve it as a dependency (see Stop using libs-* repo in favour of consistent use of Maven Central #23124)
• Use "spring-*" as a project name only for Spring Framework published modules. Rename internal modules accordingly ("spring-framework-bom", "spring-core-coroutines"...)
• Use Gradle Platform features for publishing the Spring Framework BOM
• Use the standard Gradle "Maven Publish plugin"
• Apply and configure the artifactory publish plugin directly (instead of delegating that to the CI server). This allows us to really control which artifacts are published, without workarounds.

[sbrannen]

Remove outdated Eclipse support (replaced by Buildship)

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?

[bclozel]

@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?

[sbrannen]

@bclozel, whenever one uses Buildship in Eclipse, the eclipse customization in the Gradle build is honored.

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 ide.gradle.

In summary, if we remove all of our eclipse customization in the Gradle build I fear that our projects will not work properly with the standard Buildship features. Hence the need to be cautious before totally removing all of that.

[rwinch]

@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]

@rwinch, I'm elaborating on that in #23234
Also, this issue will move all the dependency management in the main build.gradle file, so things should be easier to read there (versions, BOMs, exclusions, everything!).

[rwinch]

@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.