Provide mechanism for managing resources across engines and executions

[marcphilipp]

The Platform should provide an extensible mechanism (ServiceLoader?) so that user code can create "closeable resources" that are injected as part of the context received by TestEngine implementations.

This feature is analogous to the ExtensionContext.Store concept from Jupiter but takes it to the Platform level. Moreover, it allows to reuse the same resource across multiple executions in a LauncherSession. We should advocate that resources stored in such a key-value store be immutable until their destruction. If such resources implement AutoCloseable they will get closed immediately before the LauncherSession they belong to is closed.

[stale]

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.

[stale]

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.

[PinkFloyded]

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.

[terencenmnpan]

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.

[marcphilipp]

@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.

[YongGoose]

@marcphilipp @terencenmnpan @PinkFloyded

any updates?

[marcphilipp]

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

[YongGoose]

@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.

[marcphilipp]

Sure, no worries! 👍

[YongGoose]

@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 some level of 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.

[marcphilipp]

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.

[YongGoose]

@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 proceed with 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.