"Richard S. Hall" <[EMAIL PROTECTED]> writes: > So, that is basically the standard algorithm for using the OBR API: > > 1. Get a resolver. > 2. Add desired resources to the resolver (discovered through the > repository admin interface).
Can some of these "desired resources" be already available locally? See below. > 3. Resolve the resolver's set of resources. > 4. Deploy if successfully resolved, print error message if not. I still think there's a gap between this procedure and what I'm trying to do. My goal is to be able to take URL to a bundle that's mostly on the local disk, install that bundle, and then go find some way to acquire other bundles to satisfy this first bundle's requirements or dependencies. The OBR interface (and its use in ObrCommandImpl and ObrProbe) /looks/ like it's based on first selecting some some resource expected to be available remotely (by way of the searchRepository() method), but in my case I expect that resource to be available locally. I only want to look for its dependencies remotely (if they're not already satisfied locally in my bundle cache). (I'll note here that I don't understand why the first thing ObrCommandImpl.searchRepository() does is look for the desired bundle in the local BundleContext, only to turn around and search for it remotely. If we find it locally, why would need to find it in a remote location too?) Maybe what I'm missing is some kind of interface to the resolving process for a locally-installed bundle that I'd like to start up. If I install a bundle which may have unsatisfied dependencies, how can I go about finding other bundles that can satisfy those dependencies? Does the OBR API address this need? It looks like the RepositoryAdmin.discoverResources() method would help, but how would I construct the appropriate filter expression from a given bundle I have in hand? -- Steven E. Harris
