Re: [orbit-dev] Optional Dependencies in Recipes.

[Roland Grunberg <rgrunber@xxxxxxxxxx>]

> > Line 12:  *
> > Although I didn't do this on the other lucene bundles, should we change the
> > fallback to '*;resolution:=optional' in a separate commit ?
> > 
> > Initially I felt this makes it more work for packagers because if they miss
> > any dependencies it can cause problems. One can still use wildcards, just
> > not in this exact manner.
> 
> I discovered that OSGi-ifying a library should force people to think about
> dependencies. A lot dependencies in a specific library are not required. For
> example, a lot Guava code can be used without sun.misc. If an import-package
> statement is not optional it makes the dependency greedy. My intent with
> adding "optional" to the default template was to make dependencies
> non-greedy by default and have recipes authors make the greedy ones
> explicit. I do expect recipe authors to know the dependency tree of a
> recipe.

Yes, so just to clarify, the default is still '*;resolution:=optional' and I
think this is fine. Although any time a person is contributing for the first
time and we see a bnd file with no hard requirements we should probably confirm
that's actually what they want.

I had noticed I neglected to put the "optional resolution" fallback in for
Lucene 5.x and wondered whether we should change Lucene Queries to do things
properly and then go back and fix the existing Lucene 5.x stack as well.


> In a perfect world we could remove the * (catch-all) import and fail a recipe
> build if any dependency is not covered in the bnd file. But it seems that
> bnd has no option to fail for such a missing entry?

Looking at https://github.com/bndtools/bnd/issues/138 the tool seems to have an
option to warn if a referenced import cannot be resolved (pedantic) so hopefully
it can do the opposite as well.

If not, I wonder if using something like jdeps (new in JDK 8) can be used to
get a list of static dependencies and see if they all match some term element
of Import-Package from the osgi.bnd. Probably something to look into for future.

Cheers,
-- 
Roland Grunberg