Well, it looks like in the 6.0 they did away with having a distinct version for the JUnit platform (https://docs.junit.org/6.0.0/release-notes.html). Guess that confused too many people. 😵💫
Given that, I imagine simply going with the JUnit 6 module will be the way to go. On Sun, Apr 5, 2026 at 4:23 AM Paul King <[email protected]> wrote: > Okay, I'll proceed with the previously discussed proposal for alpha-1. If > creating junit6 turns out to be the wrong choice, I think we can adjust > course before we get to beta-1. > > On Sun, Mar 29, 2026 at 7:29 AM 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. >> >
