Relocate arquillian-junit-5-* to arquillian-junit-jupiter and add JUnit 6.x testing

[rhusar]

Fix #805 and #808

Core design:

Rename artefactId and groupId to remove explicit 'junit5' reference.
Add relocation POM.
Does NOT rename packages.

Summary by Sourcery

Relocate the JUnit 5 integration to new arquillian-junit-jupiter artifacts and introduce infrastructure to verify compatibility with JUnit 6.

New Features:

• Add a JUnit 6 Maven profile that tests the JUnit Jupiter modules against JUnit 6 on Java 17 and 21.
• Introduce a relocations module providing compatibility artifacts for the old arquillian-junit5 coordinates.

Enhancements:

• Rename and repackage the existing JUnit 5 modules to arquillian-junit-jupiter-* and update references throughout the build and BOM.
• Clarify BOM dependency sections to distinguish JUnit 4.x, JUnit Jupiter, and the relocated JUnit 5.x artifacts.

CI:

• Extend the GitHub Actions CI pipeline with a job that runs the JUnit Jupiter modules under the JUnit 6 profile on supported JDKs.

Summary by Sourcery

Rename the JUnit 5 integration modules to JUnit Jupiter, introduce relocation artifacts for the old coordinates, and add infrastructure to test compatibility with JUnit 6 in CI.

New Features:

• Add a Maven profile that runs the JUnit Jupiter modules against JUnit 6.x on Java 17 and 21.
• Introduce a relocations parent module providing compatibility POMs for the legacy arquillian-junit5 core and container artifacts.

Enhancements:

• Rename and re-parent the JUnit 5 modules to arquillian-junit-jupiter-* and update BOM and integration tests to use the new group and artifact IDs.
• Clarify the BOM dependency sections to distinguish JUnit 4.x, JUnit Jupiter, and relocated JUnit 5.x artifacts.
• Add an animal-sniffer configuration to enforce Java 8 API compatibility for the build module.

CI:

• Extend the GitHub Actions workflow with a matrix job that verifies the JUnit Jupiter modules using the JUnit 6 Maven profile on supported JDKs.

[sourcery-ai]

Reviewer's Guide

Renames the JUnit 5 integration modules to JUnit Jupiter coordinates, adds relocation POMs for the old junit5 artifacts, and introduces a JUnit 6 test profile that is exercised in CI on Java 17 and 21 while tightening Java API compatibility via animal-sniffer.

Flow diagram for CI junit6-verify job using Maven junit6 profile

graph TD
  GH[GitHub Actions workflow ci.yml]
  Job[junit6-verify job]
  Matrix[Java matrix 17, 21]
  Maven[mvn clean verify -Pjunit6 -pl junit-jupiter/core,junit-jupiter/container -am]
  Profile[build/pom.xml junit6 profile<br/>sets version.junit-jupiter 6.0.2]
  Modules[junit-jupiter/core and junit-jupiter/container]

  GH --> Job
  Job --> Matrix
  Matrix --> Maven
  Maven --> Profile
  Profile --> Modules

Loading

File-Level Changes

Change	Details	Files
Introduce a JUnit 6 testing profile and enforce Java 8 API compatibility for the build modules.	Rename the shared JUnit 5 version property to version.junit-jupiter and reuse it for the junit-bom import. Add the animal-sniffer-maven-plugin to verify modules only use Java 8 APIs using the java18 signature at the verify phase. Add a junit6 Maven profile that overrides version.junit-jupiter to 6.0.2 for testing against JUnit 6.	build/pom.xml
Extend CI to verify JUnit Jupiter modules against JUnit 6 on modern JDKs.	Add a junit6-verify GitHub Actions job that runs on Java 17 and 21. Configure the job to build only the junit-jupiter core and container modules with the junit6 Maven profile, resolving dependencies as needed.	.github/workflows/ci.yml
Rename JUnit 5 integration modules to JUnit Jupiter and update all internal references.	Rename the junit5 parent module to junit-jupiter and update the root modules list. Change groupId/artifactId pairs from org.jboss.arquillian.junit5:arquillian-junit5-* to org.jboss.arquillian.jupiter:arquillian-junit-jupiter-* in the core and container POMs. Update module names and descriptions to refer to JUnit Jupiter instead of JUnit 5. Adjust integration test dependencies to point at the new junit-jupiter container artifact.	pom.xml junit-jupiter/pom.xml junit-jupiter/core/pom.xml junit-jupiter/container/pom.xml integration-tests/junit5-tests/pom.xml junit-jupiter/README.adoc
Clarify BOM structure and add entries for the new JUnit Jupiter artifacts while keeping references to the legacy coordinates.	Annotate existing JUnit entries as JUnit 4.x in the BOM for clarity. Add dependency management entries for the new arquillian-junit-jupiter-core and arquillian-junit-jupiter-container artifacts. Retain the old org.jboss.arquillian.junit5 artifacts under a clearly labeled JUnit 5.x (relocated) section.	bom/pom.xml
Provide relocation POMs to preserve compatibility for consumers using the old junit5 coordinates.	Add a relocations aggregator module to the main build. Create arquillian-junit5-core and arquillian-junit5-container relocation POMs that point to the corresponding arquillian-junit-jupiter artifacts via distributionManagement/relocation. Set appropriate names and descriptions on the relocation artifacts to communicate the move.	relocations/pom.xml relocations/arquillian-junit5-core/pom.xml relocations/arquillian-junit5-container/pom.xml

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#805	Rename the JUnit 5 integration artifacts (groupId/artifactId and module naming) from arquillian-junit5-* to arquillian-junit-jupiter-* to avoid confusion about JUnit 6 support.	✅
#805	Provide Maven relocation POMs so that existing consumers of org.jboss.arquillian.junit5:arquillian-junit5-* are transparently redirected to the new org.jboss.arquillian.jupiter:arquillian-junit-jupiter-* artifacts.	✅

Possibly linked issues

• Relocate arquillian-junit-5-* to arquillian-junit-jupiter #805: The PR performs the requested junit5→junit-jupiter relocation using Maven relocation and updates related build configuration.
• #: PR introduces a JUnit 6 Maven profile and CI job, effectively adding JUnit 6 support as requested.

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[rhusar]

@jamezp please have a look

[sourcery-ai]

Hey - I've left some high level feedback:

• In the relocation POMs (relocations/arquillian-junit5-core and relocations/arquillian-junit5-container), consider changing the packaging to pom and removing the explicit dependency on the new junit-jupiter artifacts so that the relocated coordinates don’t introduce unnecessary transitive dependencies and rely purely on Maven’s relocation metadata.
• The relocation modules currently inherit from arquillian-build while the relocations parent POM inherits from arquillian-parent; it may be worth aligning these parents (or documenting the rationale) to keep the module hierarchy and build configuration consistent.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In the relocation POMs (`relocations/arquillian-junit5-core` and `relocations/arquillian-junit5-container`), consider changing the packaging to `pom` and removing the explicit dependency on the new `junit-jupiter` artifacts so that the relocated coordinates don’t introduce unnecessary transitive dependencies and rely purely on Maven’s relocation metadata.
- The relocation modules currently inherit from `arquillian-build` while the relocations parent POM inherits from `arquillian-parent`; it may be worth aligning these parents (or documenting the rationale) to keep the module hierarchy and build configuration consistent.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[rhusar]

Hey - I've left some high level feedback:

• In the relocation POMs (relocations/arquillian-junit5-core and relocations/arquillian-junit5-container), consider changing the packaging to pom and removing the explicit dependency on the new junit-jupiter artifacts so that the relocated coordinates don’t introduce unnecessary transitive dependencies and rely purely on Maven’s relocation metadata.
• The relocation modules currently inherit from arquillian-build while the relocations parent POM inherits from arquillian-parent; it may be worth aligning these parents (or documenting the rationale) to keep the module hierarchy and build configuration consistent.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In the relocation POMs (`relocations/arquillian-junit5-core` and `relocations/arquillian-junit5-container`), consider changing the packaging to `pom` and removing the explicit dependency on the new `junit-jupiter` artifacts so that the relocated coordinates don’t introduce unnecessary transitive dependencies and rely purely on Maven’s relocation metadata.
- The relocation modules currently inherit from `arquillian-build` while the relocations parent POM inherits from `arquillian-parent`; it may be worth aligning these parents (or documenting the rationale) to keep the module hierarchy and build configuration consistent.

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Addressed.

[hantsy]

I wish the Arquillian core adopting JUnit 6 would be in a new major release (e.g., 2.0), and the JDK baseline would be upgraded to Java 17+ (and all API/SPI code cleaned up to Java 17).

[sourcery-ai]

Hey - I've left some high level feedback:

• In the new junit6 Maven profile, consider adding a JDK-based activation (e.g., <activation><jdk>[17,)</jdk></activation>) so that the profile cannot be accidentally enabled on Java 8/11 where JUnit 6 is not intended to run.
• The relocation POMs currently hard-code the parent version (1.10.1.Final-SNAPSHOT); aligning this with the root project version (e.g., via inheritance or a shared property) would help avoid the parent version drifting out of sync on future releases.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In the new `junit6` Maven profile, consider adding a JDK-based activation (e.g., `<activation><jdk>[17,)</jdk></activation>`) so that the profile cannot be accidentally enabled on Java 8/11 where JUnit 6 is not intended to run.
- The relocation POMs currently hard-code the parent version (`1.10.1.Final-SNAPSHOT`); aligning this with the root project version (e.g., via inheritance or a shared property) would help avoid the parent version drifting out of sync on future releases.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[rhusar]

Hey - I've left some high level feedback:

• In the new junit6 Maven profile, consider adding a JDK-based activation (e.g., <activation><jdk>[17,)</jdk></activation>) so that the profile cannot be accidentally enabled on Java 8/11 where JUnit 6 is not intended to run.
• The relocation POMs currently hard-code the parent version (1.10.1.Final-SNAPSHOT); aligning this with the root project version (e.g., via inheritance or a shared property) would help avoid the parent version drifting out of sync on future releases.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In the new `junit6` Maven profile, consider adding a JDK-based activation (e.g., `<activation><jdk>[17,)</jdk></activation>`) so that the profile cannot be accidentally enabled on Java 8/11 where JUnit 6 is not intended to run.
- The relocation POMs currently hard-code the parent version (`1.10.1.Final-SNAPSHOT`); aligning this with the root project version (e.g., via inheritance or a shared property) would help avoid the parent version drifting out of sync on future releases.

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

You are wrong - Maven profile activation by JDK would auto-activate this profile on Java 17+, which would switch everyone to JUnit 6 by default. That's not what we want

[rhusar]

Ready for review @jamezp when you have a minute, thanks.

[rhusar]

I wish the Arquillian core adopting JUnit 6 would be in a new major release (e.g., 2.0), and the JDK baseline would be upgraded to Java 17+ (and all API/SPI code cleaned up to Java 17).

Hey @hantsy I totally hear you. Here's the catch: we are NOT doing anything special for Junit 6 as that's runtime compatible with what we are producing here. Sure, it's limited by the JDK t hat Junit 6 itself supports (while we still support JDK 11 here to align with Jakarta).

So, for this to happen, we first need to even deprecate stuff properly, which I am pushing a lot, especially in #830

Basically, we/I feel that it would alienate people unnecessarily going to a major version without any real breakage/features/etc. We/I try to break as little as reasonably possible.

[hantsy]

Everything is OK now.

But I saw there is a 2.0 plan, I hope Arquillain core will use JUnitJupiter instead of JUnit5 in the code or configuration in the new coming version. It maybe introduces a little API incompatibility of renaming.