-
Notifications
You must be signed in to change notification settings - Fork 320
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
Make the generated testing InjectorProvider more flexible #3042
Conversation
Note that the old custom RuntimeInjectorProvider was removed. It was already useless because the bindClassLoaderToInstance generated already worked.
I think I like this. Small change and nice improvement. |
find . -name "*InjectorProvider.java" | grep -v /ide/ | grep -v UiInjectorProvider | wc -l
|
@cdietrich With "Quick Search" I searched for the string |
ok |
Part of #3001
As hinted here #3001 (comment) instead of generating an injector provider of this shape:
This PR generates it like that (main commit 1181731):
This section was introduced in the past for running tests in OSGI, e.g., by Maven Tycho, to get the correct class loader.
This new version makes the class loader be retrieved from the instance of the injector provider, NOT from the static class of the injector provider, as before.
Thus, simply inheriting an injector provider in another test bundle will make Guice take the correct class loader.
Instead, before, one had also to redefine the
createRuntimeModule
.This makes things easier in testing. Some examples of simplification due to this change are:
I regenerated all our languages accordingly.
Concerning purexbase, I cleaned up things a bit 8230ada : the old
RuntimeInjectorProvider
was already useless, maybe something from the past.The PR can be seen as a first step/preparation in case we want to address #3001