Document best practices for implementing ParameterResolvers

[sbrannen]

Overview

Based on discussions in #1184 and https://github.com/weld/weld-junit/issues/3, it is apparent that we need to document best practices for implementing ParameterResolver, particularly with regard to "playing nicely" with other registered ParameterResolver implementations.

Proposed Categories

After having put a bit more thought into the subject, I am tossing around the idea of categorizing ParameterResolver implementations by behavior as follows.

• explicit: support requires an annotation for disambiguation.
• implicit: support is automatic for types owned by the resolver.
• speculative: a resolver claims it can support a given parameter even if it potentially should not (a.k.a., greedy or eager).

Deliverables

• [ ] Document best practices for ParameterResolver implementations in JavaDoc.
  • more succinct than the documentation in the User Guide
• [ ] Document best practices for ParameterResolver implementations in the User Guide.
  • including examples and explanations of how to avoid conflicts

[sbrannen]

Update: added Proposed Categories section to issue.

[rumpfc]

Can you also provide examples for error/exception handling within ParameterResolver which are actually not ParameterResolutionExceptions (i.e. resolveParameter() reads a File where an IOException is thrown)?

[stale[bot]]

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[bot]]

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.

[slinkydeveloper]

Hey @marcphilipp @sbrannen, can you please re-open this issue? I think it's still relevant, as right now it's not clear how to develop a ParameterResolver that doesn't conflict with other parameter resolvers, and in particular to create one that doesn't conflict with ParameterizedTest. I'm also willing to help with the review of the doc.

My use case is that I want to create a test matrix combining several TestTemplateInvocationContextProvider, in particular my own ParameterResolver (injected through an implementation of TestTemplateInvocationContextProvider) and @ParameterizedTest.

[sbrannen]

can you please re-open this issue? I think it's still relevant, as right now it's not clear how to develop a ParameterResolver that doesn't conflict with other parameter resolvers,

Sure. I'll reopen this issue.

and in particular to create one that doesn't conflict with ParameterizedTest.

That aspect is already covered in the current documentation.

[stale[bot]]

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[bot]]

Closing due to lack of requested feedback. If you would like to proceed with your contribution, please provide the requested information and we will re-open this issue.

[jabhatfield]

PR for this issue had some formatting violations, now fixed.

[jabhatfield]

Hi @sbrannen, I've created a PR for this issue.