Handling resolution outside of the framework

[Mark Raynsford <li...@io7m.com.INVALID>]

Hello!

A few months back, I was looking into using the resolver outside of an
OSGi context. What I wanted to do was call a resolver with a set of
requirements, and have it tell me the set of bundles I need to
retrieve in order to start up an OSGi framework with everything
required installed.

I came up with this:

  https://github.com/io7m/resolver-test-20180322/blob/master/src/main/java/com/io7m/felixresolver/Main.java

Now, this works for these silly example bundles. The problem is that
real bundles contain requirements such as:

  osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=9.0))"

These will obviously fail given the resolver context in the example
program because it doesn't contain any of the capabilities that a real
framework would provide. What is the correct way to deal with this? I'm
not sure I should be inserting fake capabilities myself (it's not
entirely clear how I could even do this), and I'm not sure I could
filter requirements without prior knowledge of each and every
requirement.

-- 
Mark Raynsford | http://www.io7m.com

Re: Handling resolution outside of the framework

[Mark Raynsford <li...@io7m.com.INVALID>]

On 2018-08-26T17:43:50 +0100
Neil Bartlett <nj...@gmail.com> wrote:

> Hello Mark,
> 
> Before going too much further with this, have you looked at whether you can
> reuse the resolution code from bnd? We do exactly what you are trying to
> do, as far as I can tell from your mail, i.e. resolving a set of
> requirements outside the context of running OSGi Framework. For example
> this happens when you click the "Resolve" button in Bndtools, or run the
> bnd-resolver-maven-plugin (amongst others).
> 
> The code is here:
> https://github.com/bndtools/bnd/tree/master/biz.aQute.resolve

'Ello.

Apologies for the late reply. Using the resolution code from bnd is
certainly an option. I'm already using the bnd API for loading bundles
as Resources. When I started writing this code, I actually didn't
realize how much was involved in implementing the resolve context type.

For the eventual use I have in mind, I suspect there'll actually be
some user interaction involved in picking bundles.

-- 
Mark Raynsford | http://www.io7m.com

Re: Handling resolution outside of the framework

[Neil Bartlett <nj...@gmail.com>]

Hello Mark,

Before going too much further with this, have you looked at whether you can
reuse the resolution code from bnd? We do exactly what you are trying to
do, as far as I can tell from your mail, i.e. resolving a set of
requirements outside the context of running OSGi Framework. For example
this happens when you click the "Resolve" button in Bndtools, or run the
bnd-resolver-maven-plugin (amongst others).

The code is here:
https://github.com/bndtools/bnd/tree/master/biz.aQute.resolve

Regards,
Neil


On Sat, Aug 25, 2018 at 5:07 PM Mark Raynsford
<li...@io7m.com.invalid> wrote:

> Hello!
>
> A few months back, I was looking into using the resolver outside of an
> OSGi context. What I wanted to do was call a resolver with a set of
> requirements, and have it tell me the set of bundles I need to
> retrieve in order to start up an OSGi framework with everything
> required installed.
>
> I came up with this:
>
>
> https://github.com/io7m/resolver-test-20180322/blob/master/src/main/java/com/io7m/felixresolver/Main.java
>
> Now, this works for these silly example bundles. The problem is that
> real bundles contain requirements such as:
>
>   osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=9.0))"
>
> These will obviously fail given the resolver context in the example
> program because it doesn't contain any of the capabilities that a real
> framework would provide. What is the correct way to deal with this? I'm
> not sure I should be inserting fake capabilities myself (it's not
> entirely clear how I could even do this), and I'm not sure I could
> filter requirements without prior knowledge of each and every
> requirement.
>
> --
> Mark Raynsford | http://www.io7m.com
>
>