Hello Gunnar, Am 24.05.2012 um 12:18 schrieb Gunnar Wagenknecht:
> Am 24.05.2012 11:33, schrieb Dennis Hübner: >> You say "must", is the last year default deprecated? > > I think it's not explicitly deprecated. But it's "legacy". ;) @David It's not obligatory! So don't nag on project who use this optional greedy combination. :p > >> However we have over 250 optional dependency entries in 53 >> bundles, instead of creating 53 p2.inf files I used the x-installation >> instruction: >> ;resolution:=optional;x-installation:=greedy, > > Yes, that works as well. It's a much easier way. However, I'm wondering > if the report should have detected those as "explicit" and not as "old > default". Are you using the new publisher? We use the latest buckminster so, yes we do. > >> I tried to make our "product" behaves exactly the same as before the new >> default. > > I don't know your product well enough. Are those optional dependencies > necessary for the product or the bundle as well? You may not need to > explicitly set the greedy setting everywhere. Sometimes the new default > is also ok. > Yes, it's true. We are going to reduce the count of optional greedy dependencies. > IMHO a bundle uses 'resolution:=optional' to indicate either that a > dependency is only necessary when additional functionality is wanted (a) > or that additional functionality is available when the dependency is > available (b). > > I see (b) purely as a user driven use case. For example, if Mylyn is > available then integrate with Mylyn but do not install Mylyn when my > bundle is installed. This use case should not use the greedy setting. > > A packager might want to provide a "my feature + Mylyn" package. That > can be achieved by creating a feature (or product) which combines both. > But then greedy also isn't necessary because the feature.xml makes an > explicit reference. I see one more constellation. A user installs tool X and you know that tool Y is also very useful if one use tool X, so if a tool Y repository is available/active it should be installed for better user experience. optional greedy case. > > For (a) some downstream consumer (another bundle) may require the > dependency because it knows that it calls some extended API that > requires the optional dependency. I think in this case the downstream > consumer should define a non-optional dependency anyway so greedy isn't > technical necessary. Unfortunately, we reexport some of our optional dependencies it's very important for, our downstream projects that this dependencies remain greedy. Regards, Dennis. > > HTH, > Gunnar > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev