Thanks for the proposal, @translatenix.

We'll discuss it within the team during an upcoming team call and get back to you.

Team decision: Introduce junit.jupiter.extensions.autodetection.include and junit.jupiter.extensions.autodetection.exclude configuration parameters with defaults of * and empty, respectively.

Addendum: The new properties should support the same pattern matching syntax supported for other configuration parameters.

One use case would be to enable org.mockito.junit.jupiter.MockitoExtension from org.mockito:mockito-junit-jupiter globally by default. This would activate strict stubbing then. mockito/mockito#769.

Can I Contribute?

Hi @dev-jonghoonpark,

Can I Contribute?

Yes, feel free to submit a PR for review.

@marcphilipp

Team decision: Introduce junit.jupiter.extensions.autodetection.include and junit.jupiter.extensions.autodetection.exclude configuration parameters with defaults of * and empty, respectively.

It seems like junit.jupiter.extensions.autodetection.include and junit.jupiter.extensions.autodetection.exclude should be designed to accept more than one input, is that correct?

I think it should be able to accept multiple folders and multiple classes.

Yes, comma-separated entries with wildcard matching.

hello.

I've been thinking about how to implement this feature, and I've come up with 2 approaches.

Basically, both approaches involve replacing the extension that is registered in registerAutoDetectedExtension method.

1st approach

main...dev-jonghoonpark:junit5-forked:implement-all-callbacks

Create an AutoDetectedExtension that implements all possible callbacks.

Let the AutoDetectedExtension contain the originalExtension and perform the callbacks when conditions are matched.

Disadvantages :

• have to check for callbacks that are not actually implemented.

2nd approach

main...dev-jonghoonpark:junit5-forked:use-proxy

Use a proxy to intercept the callback function when it is executed and check the path. If it matches the conditions, perform the callback.

Disadvantages :

• have to use a proxy (which can get complicated).

I'm going to try the first of the two approaches, what do you think?
(Note that the above code is just written to check the approach, it's not the finished code).

If you have a better way, I'd love to hear about it, even if it's a completely different approach.

Thank you.

@dev-jonghoonpark Thanks for looking into this and sorry for not getting back to you sooner!

Auto-registration of extensions is already implemented here:

Therefore, all that should be needed is to implement filtering of the classes loaded via ServiceLoader based on the two new configuration parameters before calling registerAutoDetectedExtension:

For the filtering, exclusions are already implemented in ClassNamePatternFilterUtils and you'll have to add support for inclusions.

Please let me know if you have any questions.

I've already worked on this in my personal repository, and since there’s a large amount of code changes, I decided to split it into two PRs.

• YongGoose@a2ef07f

I plan to proceed in the following two ways.

1. Add an include method to ClassNamePatternFilterUtils.
2. Implement include and exclude filtering when calling registerAutoDetectedExtensions in MutableExtensionRegistry.

• Add include matching on ClassNamePatternFilterUtils #4115

The link above is the PR for the first step.

@YongGoose Thanks! I'll take a look in the next few days! 👍