-
Notifications
You must be signed in to change notification settings - Fork 38k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open parameter autowiring utility for external use #2060
Open parameter autowiring utility for external use #2060
Conversation
Hi @ledoyen, Would you mind opening a JIRA ticket to request this feature so that we can better track it and discuss it? For example, if we open up this API we would need to consider where this utility class should live. In other words, if we make it public, it is rather unlikely that it would remain in the Jupiter-specific package in Also, I would like to know how you intend to use this in "other test frameworks". Thanks, Sam |
Sure thing, I thought this kind of change fall under the scope of 'trivial' cases. Here it is : #19926. I intent to use this in a test framework I am building to support specification by example workshops: Glacio. I think that the extension way of JUnit5 is very inspiring as it allow composition of plugins and I would like to have that same easiness of composition in Glacio. This is for example different from cucumber-jvm where test classes lifecycle is handled by the extension (the |
Let me know if you need me to change the PR to change package, add specific tests, etc. |
Well, if we only change the visibility of the class and methods, then yes it is rather trivial, but we may do more than that. 😉
Thanks
Thanks for the link. I'll take a look.
I'm glad you like it!
Understood. |
Yes, but for now it is merely a proof of concept. |
Updated status to "pending-design-work" |
FYI: this issue is closely related to #18628. |
If However, since @jhoeller, are you OK with the above proposal? |
Team Decision:
I'll update the Deliverables for this issue accordingly. |
OK, @ledoyen, I've updated the Deliverables for this issue. Do you have time to rework the PR to cover those tasks? If so, please let us know approximately when you think you can do that. If you don't have time to do that within the coming week or so, I may go ahead and complete the tasks. So, thanks in advance for feedback! Sam |
Yes I have time to work on what have been decided. However, as the two public methods of Furthermore, methods of |
Great!
I think they do. When a class is opened up for direct use by the public, I prefer to have local unit tests in place. But if you don't have time for that, don't worry about it: I can pick up that task after the merge.
Oops! You're totally right.
Technically speaking, I guess the main question is "Do we want to have the 'instance of
The downside of the latter choice is that third-party clients of I am therefore leaning toward moving @jhoeller, thoughts? |
This commit is a prerequisite for spring-projectsgh-2060.
Sounds good to me. I will ge back to you with some code tomorrow evening if that is ok to you. |
Here is the proposal, hoping Deliverables have the required quality. |
Yep, I think looks pretty good. Thanks! |
This has been merged into |
Further refinements were pushed in 6f6be27. |
Thanks for pointing that out ! |
If you're referring to the "refinements", sure... no problem! By the way, the build was also broken due to CheckStyle violations, but I fixed that in f2a5415. Those CheckStyle violations catch me by surprise every time. |
Checkstyle may run in PR checks (I think I have seen that of the PMD project), so that eventually external commiters can correct that by themselves. |
Would you mind opening a new GitHub issue to address that? |
Done : #22487 |
Thanks |
@sbrannen I'm afraid we have to take a step back and move those two new methods to a utility in |
Maybe a |
On review, this looks like an ideal location indeed, right next to the annotation types that it actually resolves (also right next to the analogous If there are no objections to the name |
Thanks for catching the cycle, @jhoeller! 😱 It sounds like moving it to As for the name, just go with your Cheers |
Background
This PR is to open utility methods used by the
SpringExtension
for JUnit Jupiter inspring-test
.These mechanisms can be used in other test frameworks, and are already very well documented and tested.
Proposal
Open autowiring utility methods in
ParameterAutowireUtils
, so they can be used by other frameworks.Deliverables
AutowireUtils
public
and declare its current methods as package-private.ParameterAutowireUtils
toAutowireUtils
and make theisAutowirable()
andresolveDependency()
methodspublic
.SpringExtension
to useAutowireUtils
instead ofParameterAutowireUtils
.ParameterAutowireUtils
from thespring-test
module.AutowireUtilsTests
forisAutowirable()
andresolveDependency()
.