It's easy to forget that the Eclipse IDE isn't the only environment
where OSGi bundles can be used and that the Eclipse release train
isn't the only distribution channel. In many cases it makes a lot of
sense to declare a wish to "install X if it is available and doesn't
cause conflict" and that's actually what the optional attribute was
designed for. I can understand why this in some cases could be
considered bad practice in the limited scope the release train
(after all, everything is indeed available so it will be installed),
but it's often necessary to think beyond that scope when packaging
general purpose bundles.
For bundles commonly installed in the IDE, an optional + greedy will
cause no harm. As Laurent points out, they will be present anyway.
In other environments this combination is very useful. I must
confess that I don't understand why projects that exploit this
feature are hunted down and blamed. It seems to me that everyone
suspects that they don't know what they are doing. Obviously they
Just my 2c,
On 05/29/2012 10:06 AM, Thomas Hallgren wrote:
On 05/29/2012 09:35 AM, Laurent Goubet wrote:
No, you're not wrong. This is exactly the kind of scenario that
the greedy attribute was supposed to cover.
Some bundles from Acceleo (org.eclipse.acceleo.*) appear in this
list. For example :
Number of IUs using optional, but greedy for this case: 2
Acceleo is developped as an Eclipse plugin, yet it is also
meant to be useable in a standalone environment. When
installed in Eclipse, we depend on org.eclipse.core.* bundles
to provide additional functionality and integration. However,
none of these dependencies are mandatory when using it as a
standalone generation tool. So yes, we are indeed greedy (but
in fact, it should be quite difficult to _not_ have
o.e.c.filesystem installed before us right?
org.eclipse.core.runtime and org.eclipse.core.resources should
probably be ignored too by this report), _and_ optional since
the dependency is not really needed in other environments.
I believe that these cases should be exceptions to the
"greedy" report. How could we document/track these? Or is my
understanding wrong here?
cross-project-issues-dev mailing list