On Wed, Mar 3, 2010 at 19:14, Arjun Panday <[email protected]> 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 api. 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 second. 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 that. > /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. >> >> > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
