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.
Not sure to understand what you expect here. Using the NO_LOCAL_RESOURCES flag should have roughly the same effect as removing the local repository from the list of repositories used by this resolver. The DO_NOT_PREFER_LOCAL flag will change the behavior of the resolver to not prefer local resources over remote resources. I think you're right that if we use the NO_LOCAL_RESOURCES flag, it does not make sense to remove the local resources from the set of required and optional dependencies. I'll fix 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 > Do you think you could provide a repository and the expected output of your resolution ? The algorithm should not have changed but a few minor fixes. Do you have mandatory attributes ? That could explain the problem ... > > /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
