I've been chewing my cheek a bit on this during some free time in the past few days.
It does seem a bit weird to me that we'd publish distinct modules for every version of JUnit Jupiter. The way I understand the Junit Platform was designed, based on https://docs.junit.org/6.0.3/overview.html, is that you've got a JUnit platform version (still 1.x in JUnit 6). The platform is the only real dependency that the main code in either the junit-5 or junit-6 modules *need, *based on the imports of groovy.junit5.plugin.GroovyJUnitRunnerHelper and groovy.junit6.plugin.GroovyJUnitRunnerHelper. Yes, we've put others into the Gradle file and, by extension, the published pom, but there's nothing that requires that. I'm inclined to think we could have one `groovy-test-junit-jupiter` module, as you described, that we publish that doesn't depend on *any* particular version of JUnit (beyond requiring 5+), and then consumers could switch to later versions as they had need. That might require artifact relocation <https://maven.apache.org/guides/mini/guide-relocation.html> if we want to replace the existing junit-5 module with it. Alternately, we could just publish a new groovy-test-junit-jupiter that removed the dependencies requiring JUnit 5 or 6, make the current junit-5 module depend on that and keep publishing it for a while for backward compatibility, but point people to use groovy-test-junit-jupiter going forward and specify the JUnit 6 (or 7, or 8, and so on...) version themselves. For the people who are *wanting* to use JUnit, this shouldn't be too unfamiliar. We could still specify junit 6 or whatever as a test dependency of the groovy-test-junit-jupiter module, but that might give us a little more freedom of movement for future upgrades. My gut feel is it makes more sense to just have the `jupiter` plugin and document how people can specify the JUnit version themselves in consuming projects. I respect the "batteries included" goal, but I'd be willing to wager that we could document how to switch in a way that wasn't too onerous. That's my two cents! Very open to disagreement. Best, Jonny On Sat, Mar 28, 2026 at 4:30 PM Paul King <[email protected]> wrote: > Hi folks, > > In the following PR, I bumped our own internal testing framework to JUnit > 6: > > https://github.com/apache/groovy/pull/2412 > > Bumping a dependency is typically a business-as-usual activity that > wouldn't need to be mentioned in the mailing list. But there was a > design choice that is worth discussing. > > Our usage of JUnit 5 was two-fold. We use it for internal testing. We > still have tests written for JUnit 3 & 4, but Eric has been doing some > nice work migrating more of our tests to JUnit 5. Migrating to JUnit > 6, after a few small wrinkles, went smoothly. We should note that the > JUnit 3 & 4 runners are now deprecated in JUnit 6. So for some future > Groovy version, we may want to deprecate support for JUnit 3/4 which > would include things likeGroovyTestCase and so forth. I don't propose > we do that just yet but we should keep an eye on jupiter evolution. > > The other usage of JUnit5 is in our runner in the groovy-test-junit5 > module. The runner lets you run JUnit 5 scripts standalone in the > groovyConsole or on the command-line. There is a JUnit platform > console launcher these days but it isn't as nice for Groovy > developers. So I propose we keep the runner. > > The way we package groovy-test-junit5 is worth thinking about. As well > as the runner, we reference all the needed jupiter implementation jars > as dependencies. So users can simply depend on that module and get > everything they need. Now, it seems a little strange to reference > groovy-test-junit5 and bring in jupiter version 6. So, we could rename > that module to junit6 or jupiter, keeping the old one around as > deprecated for backwards compatibility. > > I initially thought renaming to groovy-test-jupiter would be the best > approach since that might save us from doing more work when (and if) > there is a JUnit 7. But, after going through the implementation steps > involved, I now think groovy-test-junit6 would be best. That lets our > users just jump from JUnit 5 to 6 by changing one Maven coordinate. I > can also see a few features we can add that would enhance jupiter but > they depend on specific jupiter versions, so it would make sense to > place them in the respective version modules. There would be some > duplication in the runner code between junit5 and junit6 modules but > its only small and I propose we live with which will make eventually > deprecating the junit5 stuff easier. > > So to summarise, I propose a `groovy-test-junit6` module to live > alongside the `groovy-test-junit5` module but you'd only ever want one > of them. The `groovy-test-junit5` module will become an optional > module. I.e., not included in groovy-all and not included in the > standard distribution. That is what is in the PR, so feel free to try > it out. > > Any thoughts? > > Thanks, Paul. >
