Spring Explore ways to publish useful dependency metadata

While refactoring the Spring Framework build in #23282, we've found that the optional dependencies published with the POMs are misleading. As seen in #23234, some developers consider this information as: * telling how a Spring application should consume Framework dependencies, * recommendations about versions * how to enable support for a particular library, etc.

As describe in https://github.com/spring-projects/spring-framework/issues/23234#issuecomment-521153626 we've found that many published optional dependencies are misleading in that sense. The Maven reference documentation states that optional means:

In the shortest terms, optional lets other projects know that, when you use this project, you do not require this dependency in order to work correctly.

Instead of providing information that is misinterpreted by developers, the team decided to not publish that information. Note that the Spring Framework project not only still publishes a valid POM, but also that it's being built with Gradle and that mapping a custom Gradle configuration to a Maven optional scope was dubious in the first place.

The Spring Framework team will explore other ways to publish useful metadata for consumer projects.

Comment From: bclozel

See 561af5f8f9

Comment From: bclozel

Rather than publishing information about how Spring Framework has been built, we'd rather try and provide useful information for consumers.

We could provide information about: 1. 3rd party libraries compatibility and support 2. Spring Framework spec requirements

Case 1) is interesting, but I think it was covered by the now retired Spring IO Platform; it's been replaced with the Spring Boot BOM, which can be used by non-Spring Boot projects. The advantage of that approach is that the Spring Boot team has a semi-automated process for updating 3rd party dependencies and is checking compatibility with a large test suite. The Spring Framework build cannot compete here.

Case 2) is currently taken care of with wiki pages for each Spring Framework generation, as checking such requirements is tied to migrating to newer framework generations (here is the 5.x generation section). We can also think about important dependencies such as Kotlin, Reactor, etc.

Spring Framework is very flexible, so almost everything is optional and supported version ranges are often quite large.

Maybe we could use the Spring Framework Maven BOM to publish additional metadata, as such requirements are not linked to a particular project module, but to the whole framework.

Adding metadata to our Java Platform?

We're already publishing version constraints for all the Spring Framework modules, maybe there is a way to have additional information there?

Here's an example with the Servlet spec:

dependencies {
    constraints {
        // publish constraints for all Spring Framework modules
        parent.moduleProjects.sort { "$it.name" }.each {
            api it
        }
        // declare additional constraints
        runtime('javax.servlet:javax.servlet-api') {
            version {
                require '3.1.0'
                prefer '4.0'
            }
            because 'Spring Framework requires Servlet 3.1+'
        }
    }
}

Such metadata involves a lossy process when exported to the Maven BOM, and this results in:

      <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-websocket</artifactId>
        <version>5.2.0.BUILD-SNAPSHOT</version>
        <scope>compile</scope>
      </dependency>
      <dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>javax.servlet-api</artifactId>
        <version>3.1.0</version>
        <scope>runtime</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

So I'm wondering if that's really where we want to go. As far as I understand, unless you're publishing "a platform" like the Spring Boot BOM, you should only list dependencies that you're publishing yourself and avoid unwanted interactions with other BOMs.

Comment From: bclozel

We didn't find proper ways to express that information in our build, so it can't be exported as part of our artifacts metadata. I'm closing this issue as we won't solve this.