Avoid Adding Duplicated JUnit Entries on Classpath

[dnestoro]

Fix for: #305

[melix]

I am a bit confused by this issue. IMO, the version of JUnit declared by users should take precedence. This means that whatever JUnit version we need should only be needed at compile time of native build tools, not runtime. So it's probably a dependency scope mistake (implementation instead of compileOnly). We shouldn't rely on dirty tricks to remove jars by hand from classpath.

[melix]

@sbrannen @sdeleuze We need your inputs in order to accept or reject this PR. In order to fix this issue, we had to make several changes to dependencies. In particular, the junit platform native project is now compiled against one version of JUnit (whatever NBT wants to use), but will not "leak" these dependencies to consumers, so that they can use whatever version of JUnit they prefer (which may be a downgrade).

While this works, this is a breaking change, because now consumers have to add the junit-platform-launcher dependency to their projects in order to run native tests, similar to how we changed our own tests. Is this acceptable?

Second, and more problematic, our code depends on Junit Platform legacy reporting. I have no idea why this code is here, because our tests seem to show that it works well without. Therefore, what we've done is simply catch the error at runtime, and avoid failing if junit-platform-reporting is not on classpath. If it is required on a user project then the dependency would have to be added explicitly. We haven't found a condition that we could use to display a warning if the dependency is missing (we don't want to warn if it's redundant).

Any ideas?

[sdeleuze]

Let's discuss that in our next meeting.

[sbrannen]

now consumers have to add the junit-platform-launcher dependency to their projects in order to run native tests

That is (unfortunately) already the case for Gradle 8+ users due to a change in Gradle.

And we document that for JUnit users.

Declaring a dependency on junit-platform-launcher

Even though pre-8.0 versions of Gradle don’t require declaring an explicit dependency on junit-platform-launcher, it is recommended to do so to ensure the versions of JUnit artifacts on the test runtime classpath are aligned.

Moreover, doing so is recommended and in some cases even required when importing the project into an IDE like Eclipse or IntelliJ IDEA.

However, Maven Surefire and Failsafe do not require that users do that and instead figure out which version of the junit-platform-launcher via custom resolution logic.

[sdeleuze]

If we decide to merge this PR, maybe we could bump NBT version to 0.11.0 to be more explicit about this potential change of behavior.