This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. Thank you for your contribution.

This issue has been automatically closed due to inactivity. If you have a good use case for this feature, please feel free to reopen the issue.

Hi @marcphilipp, if there is interest in this feature, I can take a stab at implementing this. Though I'm pretty new to the Junit codebase and would have to familiarize myself first.

Hi @marcphilipp, if there is interest in this feature, I can take a stab at implementing this. Though I'm pretty new to the Junit codebase and would have to familiarize myself first.

I have interest, I'm interested in making an attempt at a change based on this for the cucumber jvm project.

@PinkFloyded @terencenmnpan Thanks for offering! Has either of you already put some thought into where/how you'd envision the Launcher API to change? I think starting on this will require a core team decision first but a concrete proposal would speed things up.

@marcphilipp @terencenmnpan @PinkFloyded

any updates?

@YongGoose No, there are no updates. Are you interested in writing up a (short) proposal for discussion?

@YongGoose No, there are no updates. Are you interested in writing up a (short) proposal for discussion?

Yes, I'm interested in writing up a proposal. However, it will take me a few days to conduct a thorough analysis and put together a detailed proposal.

Sure, no worries! 👍

@marcphilipp
I apologize for the delay in preparing the proposal.🥲
I’m still working through some thoughts and plan to start writing it after completing the following two tasks.

• Implement include and exclude filtering when calling registerAutoDetectedExtensions in MutableExtensionRegistry #4120
• Support parallelization in junit-vintage-engine #4135

I could work on the proposal at the same time, but I’ve decided to focus on the current tasks first to ensure the best quality for the project.

One idea I had in the meantime would be to build upon #3064. We could create both a session-level and request-level instance of NamespacedHierarchicalStore. The former could be exposed to registered LauncherSessionListeners via LauncherSession.getStore(). The latter would be created in the Launcher for every LauncherDiscoveryRequest and use the session-level store as its parent. It would then be exposed to test engines via EngineDiscoveryRequest and to TestExecutionListeners via TestPlan. JUnit Jupiter (and other engines) would then use the request-level store as parent when creating the store for JupiterEngineExtensionContext.

@marcphilipp

The comment was truly awesome 👍🏻 #2816 (comment)

While writing the proposal, I initially considered a single-instance structure similar to TestNG's IAttributes.
However, I decided to retain the hierarchical structure, as it seems to be more effective for managing data.

So instead of completing the proposal, I implemented the comment within my personal workspace.

The work has been divided into several steps:

1. Designing a class to manage context at the platform level (YongGoose@5bfe6ad)
2. Adding a session-level store to LauncherSession (YongGoose@7992634)
3. Adding a request-level store to Launcher
4. Exposing the request-level store in EngineDiscoveryRequest and TestPlan
5. Utilizing the request-level store in JupiterEngineExtensionContext

If my implementation approach is suitable, I am willing to contribute.

However, if the JUnit team has already decided to handle the implementation,
I would like to participate (even if just a little 😁), in the discussions on the design direction and contribute to the project in any way I can.

1. Designing a class to manage context at the platform level (YongGoose@5bfe6ad)

I think we only need a copy of Jupiter's Namespace class

If my implementation approach is suitable, I am willing to contribute.

However, if the JUnit team has already decided to handle the implementation, I would like to participate (even if just a little 😁), in the discussions on the design direction and contribute to the project in any way I can.

Nobody from the team has already started on this so it's yours for the taking. However, may I kindly suggest we finish your other PRs first? 😅

I think the steps you're proposing sound good! 👍

We'll also have to think about how a Jupiter extension (or equivalent extension of another test engine) could store something in the session- or request-level store. We'll probably have to add NamespacedHierarchicalStore.getParent() : Optional<NamespacedHierarchicalStore<N>> for that and methods like getSessionLevelStore() : Store and getRequestLevelStore(): Store to ExtensionContext.

Nobody from the team has already started on this so it's yours for the taking. However, may I kindly suggest we finish your other PRs first? 😅

Sounds great!

Once I finish this PR, I'll follow your suggestions to design and implement it accordingly!

• Support parallelization in junit-vintage-engine #4135

@marcphilipp

While working on this issue, I created a Draft PR to ask questions along with the code if needed❕

• Provide mechanism for managing resources across engines and executions #4252

I’m doing my best to understand and implement the issue, but there might be areas where I fall short.
If there are any mistakes or areas for improvement, I’d greatly appreciate your feedback! 🙂