I am trying to fix the deprecation described in #36724. In doing so, I am trying to actually invoke the related code as we don't seem to have any test for it.

Creating a fresh project from start.spring.io with Native and excluding the JUnit platform still isn't calling that code:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
    <exclusions>
        <exclusion>
            <groupId>org.junit.platform</groupId>
            <artifactId>*</artifactId>
        </exclusion>
    </exclusions>
</dependency>

I have confirmed that dependency:list doesn't show those jars. Something is adding them, my best guess is maven itself when a ResolutionScope.TEST is required for a mojo. A debug log hasn't been really helpful.

Wondering if @philwebb or @sbrannen remember why the code was added in the first place.

Comment From: philwebb

I'm pretty sure that code was inspired from AbstractSurefireMojo which (at the time) has similar localRepository and remoteRepositories definitions.

Comment From: snicoll

Right, but why was it needed? I am trying to actually call that code and haven't managed to do so.

Comment From: philwebb

I don't remember I'm afraid, it could well be that we just copied it because that's what surefire did.

Comment From: snicoll

OK so I've found that our nativeTest profile adds junit-platform-launcher as a test dependency. I wasn't calling dependency:list with the profile enabled 😭

I wonder why we can't just document that someone rolling out their own arrangement should do the same.

Comment From: sbrannen

OK so I've found that our nativeTest profile adds junit-platform-launcher as a test dependency.

org.springframework.test.context.aot.TestClassScanner has a direct dependency on junit-platform-launcher APIs, and that's used by org.springframework.test.context.aot.TestAotProcessor.

So that's why the nativeTest profile adds junit-platform-launcher as a test dependency.

I wonder why we can't just document that someone rolling out their own arrangement should do the same.

Maybe I missed something, but who is "rolling out their own arrangement"?

In any case, we could certainly document somewhere that use of the TestAotProcessor requires that junit-platform-launcher and its transitive dependencies are on the classpath. Perhaps in Ahead of Time Support for Tests?

Comment From: snicoll

So that's why the nativeTest profile adds junit-platform-launcher as a test dependency.

Thanks, but I wasn't really asking why we add it, but rather how I could call that code at all.

Maybe I missed something, but who is "rolling out their own arrangement"?

Maven users that do not use our parent.

In any case, we could certainly document somewhere that use of the TestAotProcessor requires that junit-platform-launcher

Sure but I wasn't thinking of that. We already throw an exception if we can't resolve the JUnit platform version to use. I just wonder why we can't extend that to throw an exception if the launcher isn't present, rather than downloading it for the user behind the scenes.

Comment From: sbrannen

I just wonder why we can't extend that to throw an exception if the launcher isn't present, rather than downloading it for the user behind the scenes.

A typical test suite should not have a dependency on junit-platform-launcher but rather only on the API for a given test engine (such as junit-jupiter-api). The build tool or IDE will provide/resolve the required JUnit Platform dependencies to run the tests.

In other words, many users would find it a bit odd to have to add an explicit dependency on junit-platform-launcher for Spring's AOT testing support when they don't have to do the same for the build tool or IDE. Phrased differently: build tools and IDEs already download "it for the user behind the scenes."

That's the rationale for why we download it for them.

Comment From: snicoll

We've discussed this today and were wondering why the dependency was added for the nativeTest profile. We thought that the Native Maven Plugin requires it but I've found some code and https://github.com/graalvm/native-build-tools/issues/305 that tells me otherwise.

There's not much else we can do given how widely this pattern of downloading the platform is.