Provide access to ExtensionContext/ExtensionStore in IMethodInvocation and Extensions.

[leonard84]

Jupiter gives its extensions access to ExtensionContext to store state(Keeping State in Extensions). Spock doesn't have this concept at the moment, instead extensions register interceptors that can have local state. This works fine most of the time, but with parallel execution new problems arise (#1272). Having a way to store and transport custom extension data similar to what Juptier provides could be an elegant solution. Furthermore, this would remove one of the major issues with supporting Jupiter extensions in a yet to come spock-jupiter module.

Classes of interest:

• org.junit.jupiter.api.extension.ExtensionContext
• org.junit.jupiter.engine.execution.ExtensionValuesStore

Please comment @spockframework/supporter

[marcphilipp]

I'm in favor of this proposal. On the JUnit side, it would mean to extract ExtensionValuesStore and maybe a few base implementations of these interfaces into junit-jupiter-api or a separate artifact. Moreover, it would mean that methods can no longer be added to these interfaces without backwards compatibility considerations.

[leonard84]

I'd prefer a separate artifact. Do you expect much change to those classes, I assumed that they are quite mature?

[marcphilipp]

Well, we have been adding new APIs for extension authors and have recently been discussing another addition. So far, these were not problematic since the ExtensionContext interface is not intended to be implemented by clients. However, if we change that now, we could always add a default implementation that throws an exception if there's no sensible default.

[kemuri-9]

the way this is worded is leading me to a conclusion to where ExtensionContext would be a core concept to spockframework (resulting in a hard/forced dependency on junit-jupiter-api). Wouldn't it be better for spock to have its concept/API for extension storage and then the spock-jupiter module will do a respective API layer mapping?

[leonard84]

You are right @kemuri-9 I've also been thinking of having only the store in the core, as this can't really be emulated via extensions. The ExtensionContext can then be implemented via an adapter in spock-jupiter.

That being said, not having to duplicate the store code, by having it in a platform artifact, would make things easier.

[Vampire]

Spock doesn't have this concept at the moment

I just stumbled upon org.spockframework.runtime.model.NodeInfo#metadata. Is that maybe the concept you said Spock does not have at the moment? At least I do not see any code in Spock that sets this metadata, so I would guess this to be the intended usage. Now with parallel running support this should probably be made volatile or properly synchronized though.

Or what is metadata used for otherwise?

[kriegaex]

Yes, it looks as if it is being copied when creating one MethodInfo from another one, but never actually set or used anywhere else.

Usually, meta data fields on nested nodes in a hierarchical structure are used for visitor patterns or so, e.g. in ASTs. Maybe this was an intended purpose here, but never implemented.

[marcphilipp]

FYI JUnit 5.10.0-M1 was released last Saturday and now contains the NamespacedHierarchicalStore abstraction.