-
Notifications
You must be signed in to change notification settings - Fork 45
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
Refresh a subset of bundles if they provide missing requirements #422
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code is fine given what it is trying to do. But I question if we can have a testcase that exhibits the behavior so we can add a test for this code path.
...ox.simpleconfigurator/src/org/eclipse/equinox/internal/simpleconfigurator/ConfigApplier.java
Outdated
Show resolved
Hide resolved
...ox.simpleconfigurator/src/org/eclipse/equinox/internal/simpleconfigurator/ConfigApplier.java
Outdated
Show resolved
Hide resolved
...quinox.simpleconfigurator/src/org/eclipse/equinox/internal/simpleconfigurator/Activator.java
Show resolved
Hide resolved
I'm not yet sure in wich form such a test-case would have to be provided, can I somehow "export" a bundle-set (metadata-only) and use it as an input for a test with simple-configurator? |
@laeubi you may not like this, but to move this forward I would like to have an option that defaults to the current behavior so we can enable this for the problematic scenarios. I would rather do that now so that the ones impacted by this issue can try out the solution without risking others. Once we get more confident in the approach then we can flip the default or get rid of the option. |
@tjwatson do you like to suggest how this should be implemented? Maybe as simple as a system property to check? |
Yes, but use |
When refreshing large sets of bundles the resolver sometimes take a choice where a requirement can't be bound even though it is there and resolvable. This adds some additional code to detect this situation and then refresh a smaller set of bundles that provide these until a max retry is reached, all bundles are resolved, or all providers have been tried to refresh already.
@tjwatson I now added this inside a block that is disabled by default and can be enabled with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM,
Thanks for putting the option to enable here. As developers we should encourage committers and contributors to test with this enabled so we can evaluate enabling this by default in the future.
When refreshing large sets of bundles the resolver sometimes take a choice where a requirement can't be bound even though it is there and resolvable.
This adds some additional code to detect this situation and then refresh a smaller set of bundles that provide these until a max retry is reached, all bundles are resolved, or all providers have been tried to refresh already.