-
Notifications
You must be signed in to change notification settings - Fork 41.1k
Make spring-test available to compile classpath of consumers of spring-boot-test #39901
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hello! Do you happen to have a small reproducer for that? |
I can make something smaller than this if it's really necessary, just happens to be what I'm working on (so zero extra effort) https://github.com/xenoterracide/spring-app-commons/blob/cfa0776cca44671fca59cfd33a404c6512597d02/module/test-app/build.gradle.kts note: the problem is in current main, and I probably won't "fix" it, but it's easier to ensure you can look at exactly what I have by sha. |
There's a lot going on in your project. The smallest possible reproducer would help to diagnose this. |
I actually think it could probably be more minimal than this, I don't think the multi-module is necessary, but it took me a bit to get to here. The java compiler diags are what emits this. the commented out I found an additional thing whilst creating this reproducer. Although requiring/providing spring-test for spring-boot-test-autoconfigure seems reasonable. spring data commons seems less so.
|
Thanks for the reproducer! Any reason why you don't use
instead of But besides that, I think we should expose the class Gradle complains about as an API dependency. |
transient dependency hell. Even if I used it, I set starters to "runtime only". I've seen real world examples of people adding compile time dependencies on things that they shouldn't have, which made updates and refactors later harder. Starters make it easier to have this problem. Imagine the dependencies that have been removed from the spring stack since spring started, that have perhaps, accidentally ended up being a hard requirement because they were there and so used. You should check this out https://github.com/autonomousapps/dependency-analysis-gradle-plugin |
This problem isn't specific to Gradle. You can see a similar warning with Maven when configured with the appropriate compiler arg:
This was generated from an app with this pom.xml: <?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>3.2.3</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<groupId>com.example</groupId>
<artifactId>gh-39901</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>gh-39901</name>
<description>Demo project for Spring Boot</description>
<properties>
<java.version>17</java.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-test-autoconfigure</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerArgs>
<arg>-Xlint:classfile</arg>
</compilerArgs>
</configuration>
</plugin>
</plugins>
</build>
</project> It also contains a single test class annotated with That said, it's considerably less likely to occur with Maven as Maven does not separate the test compile classpath from the test runtime classpath. In the pom above, there's no
This is always tricky with optional dependencies. The most elegant solution to this problem is Gradle's feature variants. We haven't embraced them yet as there's no good equivalent on the Maven side so we're left with the optional approach for now. In this case, when using optional dependencies as a solution, the question we have to answer is whether or not we think anyone should be using Looking through the public features of We may want to perform a similar analysis of |
It's not specific to Gradle know, however I don't believe Maven has the tooling that Gradle has to deal with it. Essentially Maven has no equivalent to api() as I recall. I personally am of the opinion that just because Maven can't do it doesn't mean that you should not let Gradle based consumers do it. Of course the inverse is also true as there are a few rare things that Gradle doesn't seem to be able to do. |
api(
We're going to add an |
not doing anything special here
since you're not using standard library definitions, maybe you need something like
optionalApi
either way the gradle metadata generated could be fixed by having this exposed as some kind ofapi
. At least I think, the whole optional thing makes me uncertain of what's being generated for Gradle's metadata, and I'm not looking at that atm.https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-test-autoconfigure/build.gradle#L34
The text was updated successfully, but these errors were encountered: