Support JUnit 6

[TheSouffleuringHatter]

JUnit 6 has just been released https://github.com/junit-team/junit-framework/releases/tag/r6.0.0

Please adapt weld-junit to JUnit6

[manovotn]

It appears dependabot already tried to bump the version - #296

There are some errors that need looking into.
I didn't yet check what are the changes in 6 versus 5 and how breaking it is but ideally, we want to avoid having to have two versions of weld-testing because of this.
@TheSouffleuringHatter would you like to take a stab and it and send a PR?

[dmatej]

I guess as it is a major version you will have to add another module.
https://docs.junit.org/6.0.0/release-notes/

• Min Java 17
• Removal of junit-platform-runner and junit-platform-jfr
• Removal of various deprecated behaviors and APIs
• ...

Well, I am curious what it meana for GlassFish too ... and other dependencies in the tree.

[manovotn]

I checked the changes and there are only two problems in the code/tests:

• The ClassScanning uses CollectionUtils#toUnmodifiableList() which was removed but we shouldn't use it anyway as it's junit internal API
  • Can be replaced with Collectors.toUnmodifiableList()
• In the test DisabledMethodsTest, we used now deprecated MethodOrderer.Alphanumeric for ordering
  • This can be replaced by MethodOrderer.MethodName

With that, we can keep the JUnit version at 5.x and even if users explicitly (or transitively) happen to use jUnit 6,weld extension would still work just fine.
I'd then bump JUnit to baseline 6 with the next major release of weld-testing which would be for the next CDI/Weld release.
WDYT @dmatej @TheSouffleuringHatter, does that work for you?

[TheSouffleuringHatter]

Sure @manovotn, this would definitely work out.

weld-testing v6 dropping JUnit4 support?

But if I might suggest, if you are speaking about a next major release of weld-testing, maybe it is time for a clear cut?

weld-testing v6 could:

• drop JUnit4 support (last JUnit4 release is 4 years old, JUnit Jupiter was released 06/2016)
• merge module junit-common into the JUnit5 module
• rename JUnit5 module to "junit-jupiter", which would support both JUnit5 and JUnit6

Though this would be a bigger deal, I think it is worth it for weld-testing. I tried it out with Claude, and I think I could provide a first version for such a weld-testing v6 as PR in the near future.

Appendix

(copying the error here for being found using Internet search)

Error:  Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.13.0:compile (default-compile) on project weld-junit5: Compilation failure: Compilation failure: 
Error:  /home/runner/work/weld-testing/weld-testing/junit5/src/main/java/org/jboss/weld/junit5/auto/ClassScanning.java:[318,41] cannot find symbol
Error:    symbol:   method toUnmodifiableList()
Error:    location: class org.junit.platform.commons.util.CollectionUtils
Error:  /home/runner/work/weld-testing/weld-testing/junit5/src/main/java/org/jboss/weld/junit5/auto/ClassScanning.java:[324,41] cannot find symbol
Error:    symbol:   method toUnmodifiableList()
Error:    location: class org.junit.platform.commons.util.CollectionUtils

[TheSouffleuringHatter]

I had Claude create a first draft for weld-testing v6 --> #293.
This is the "radical" version having a clean state. I thought about having bc first, but a JUnit5 class in a new package "weld-junit-jupiter"?! Or having a "weld-junit5" package for containing WeldJunitExtension? Migration of code seems necessary for weld-testing users. Maybe besides v6 there should be a v5.13 release with deprecations.
The PR is intended as a proof of concept to discuss and evaluate the design approaches, especially backward compatibility.

[manovotn]

FTR, the 5.x version has a PR fixing the problems here - #301
Sometimes this week I will also create a release with it.

[TheSouffleuringHatter]

--> #300

[manovotn]

Let's keep this issue open (even with the PR closed) as a reference and a tracker for the next major version WRT JUnit 6.

[manovotn]

A note for my future self - if we decide to change the artifact coordinates, we could leverage Maven relocation artifacts.
Similarly to what was done for CDI 5.0 - jakartaee/cdi#913

This does complicate the release process (see the comments in the PR) but allows users to consume both, the old and new coordinates while getting a warning about relocation when you try the old ones.
Obviously, this doesn't help if we also decide to move packages.