Skip to content
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

Load and register custom TestExecutionListener implementations automatically #583

Closed
sormuras opened this issue Dec 4, 2016 · 9 comments

Comments

@sormuras
Copy link
Member

sormuras commented Dec 4, 2016

What about adding support for loading custom TestExecutionListener implementations via the Service API to the console launcher?

Enhance (and document) ExecuteTestsTask#registerListeners with:

ServiceLoader.load(TestExecutionListener.class)
  .forEach(launcher::registerTestExecutionListeners);

Or add the load and register functionality to the platform DefaultLauncher itself?

@marcphilipp
Copy link
Member

I think we should add them to the DefaultLauncher not just when using ConsoleLauncher. I also proposed we do this in #542 (comment).

@marcphilipp
Copy link
Member

@junit-team/junit-lambda Any objections?

@sbrannen
Copy link
Member

sbrannen commented Dec 5, 2016

No objections. Go for it!

@sbrannen sbrannen added this to the 5.0 M4 milestone Dec 5, 2016
@sbrannen sbrannen changed the title Load and register custom TestExecutionListener implementations Load and register custom TestExecutionListener implementations automatically Dec 5, 2016
sbrannen pushed a commit that referenced this issue Dec 7, 2016
This commit introduces support for loading and registering custom
TestExecutionListener implementations automatically via Java's
ServiceLoader mechanism.

Issue: #583
@sbrannen sbrannen self-assigned this Dec 7, 2016
@sbrannen
Copy link
Member

sbrannen commented Dec 7, 2016

Resolved in 3c52d95.

@marcphilipp
Copy link
Member

This still needs to be documented in the User Guide and Release Notes. We haven't really used a consistent strategy to address that need in the past. We could reopen this issue, create a new one, or procrastinate until some poor guy wants to do a release and has to go through all the issues.

I'm in favor of the first option.

@junit-team/junit-lambda What do you think?

@sbrannen
Copy link
Member

sbrannen commented Dec 8, 2016

This still needs to be documented in the User Guide and Release Notes.

Oooooops. Yes... you are totally correct!

I'm in favor of reopening the original issue in such cases: no need to multiple issues for the same issue.

Since I prematurely closed it, I'll reopen it. 😉

@sbrannen sbrannen reopened this Dec 8, 2016
@sbrannen
Copy link
Member

sbrannen commented Dec 8, 2016

In retrospect, we need to (re)define our Definition of Done for issues. Though perhaps we should discuss that amongst the team and then document it in the wiki (and of course actually adhere to the rules).

@sbrannen
Copy link
Member

sbrannen commented Dec 8, 2016

Actually, I'll create an issue to address the DoD.

@sbrannen
Copy link
Member

sbrannen commented Dec 8, 2016

See #593 regarding the Definition of Done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants