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
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
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
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
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
Unfortunately, we reexport some of our optional dependencies it's very important for,
our downstream projects that this dependencies remain greedy.
cross-project-issues-dev mailing listcross-project-issues-dev@xxxxxxxxxxx