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

Consider binding provider implementation types using wildcard key (Bugzilla Bug 513442) #27

Open
mcculls opened this issue Oct 25, 2021 · 0 comments
Labels
enhancement New feature or request

Comments

@mcculls
Copy link
Contributor

mcculls commented Oct 25, 2021

This issue was created automatically with bugzilla2github

Bugzilla Bug 513442

Date: 2017-03-10 07:07:09 -0500
From: Stuart McCulloch <[email protected]>
To: Project Inbox <[email protected]>

Last updated: 2017-03-10 07:07:09 -0500

Comment 2812915

Date: 2017-03-10 07:07:09 -0500
From: Stuart McCulloch <[email protected]>

So provider implementations can be looked up by any of their superclasses/interfaces. Note this is different from looking up the type they provide, this is about locating the actual provider implementation itself. This is useful when the provider implements additional management interfaces.

@mcculls mcculls added the bug Something isn't working label Oct 25, 2021
@mcculls mcculls added enhancement New feature or request and removed bug Something isn't working labels Dec 31, 2021
cstamas added a commit that referenced this issue May 17, 2024
In short: now build works on both, Java 11 and Java 17 (tested with 11 and 17 Temurin on Linux).

Similar to #61 and similarly, once this merged removal of Tycho is pending.

Changes:
* update GH workflow to use mvnw (instead of implicitly provided mvn by setup-java)
* update wrapper to 3.2.0 and Maven to 3.9.1
* update all build plugins to their latest versions
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant