felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [DISCUSS] Review / release OBR 2.0.0
Date Thu, 04 Mar 2010 23:15:25 GMT
On Wed, Mar 3, 2010 at 19:14, Arjun Panday
<arjun.panday@alcatel-lucent.com> wrote:
> Hi Guillaume,
> A few comments about the new OBR:
>   * great job on the speed improvement!
>   * thanks for the new Reason API; i'd been hoping for something like this
>   * I've tried the new Resolver flags, but none of them seem to behave
>     like what i do with:
> final Repository[] repolist = _repoAdmin.listRepositories();
> Resolver resolver = _repoAdmin.resolver((Repository[]) (new ArrayList() {{
>      add(_repoAdmin.getSystemRepository());
>      addAll(Arrays.asList(repolist));
> }}).toArray(new Repository[repolist.length + 1]));
>   * when i use NO_LOCAL_RESOURCES or DO_NOT_PREFER_LOCAL, my local
>     resources are still stripped from the OBR resolution; which is
>     precisely what i'm trying to avoid.. or maybe i misunderstood
>     these flags and a new flag could be introduced to reflect the use
>     case above.

I've fixed that.

>   * more importantly, the output of the new implementation is
>     different from the previous one; namely, in my use case, it pulls
>     one additional resource that i do not need (nor want).. I haven't
>     yet managed to pinpoint the exact problem but here's what happens:
>         o i'm trying to resolve one single resource wich has a list of
>           "Require-Bundle" dependencies
>         o one of these required bundles provides packages required by
>           the other ones
>         o my OBR happens to contain another resource which also
>           exports the same packages (same version!)
>         o the new implementation now pulls that other resource while
>           the old implementation did not, so i guess the resolution
>           order has changed and it impacts the result

The algorithm has not changed.  After having a look at the repository
you sent me, I do understand the problem but I don't see why the
resolution output has changed or what we can do about it.
The problem is that the first resource has lots of requirements on
bundles.  So the resolver tries to resolve them one by one.  While
resolving the first ones, it needs an import on javax.servlet, so the
best resource for that one is selected.  Later, the servlet api is
resolved, so we end up with two bundles exporting the javax.servlet

I'm not really sure how to solve the problem.  My guess is that we'd
need some backtracking for that, but the current algorithm does not
uses backtracking because the current heuristic can't lead to
conflicts.   Resolving all the bundles requirements first can't really
be done either, because we may have multiple candidate bundles for the
same requirement, so we need to fully test one before going to the

Richard may have more thoughts on that, as he is the resolution
expert.  I don't even know how the current OSGi resolver deals with

> /arjun
> Le 03/01/2010 11:41 AM, Guillaume Nodet a écrit :
>> I've done a fait amount of changes to OBR those last weeks and I think
>> it could deserve a release asap.
>> However, i'd like to have a few people reviewing the new API so that
>> we all agree on it before starting the release process.
>> For those who haven't followed the stream of JIRA issues, here is a
>> short summary:
>>    * a new API named org.apache.felix.bundlerepository is available,
>> it's mostly based on the org.osgi.service.obr one
>>       but include a lot of small improvements
>>    * the org.osgi.service.obr isn't shipped anymore, but the if
>> present, a wrapper service will be exposed to offer compatibility
>>       with previous versions of OBR
>>    * the speed has been improved by a factor x10 or more (both parsing
>> and resolution)
>>    * ability to not resolve / install optional resources
>>    * support for requirements as an input for the resolution
>>    * support global constraints and capabilities
>> Feedback welcomed.   If there aren't any, I plan to start a release
>> early next week.

Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA

View raw message