"Richard S. Hall" <[EMAIL PROTECTED]> writes: > In truth, I wasn't much of a fan of the whole "start" flag in the > first place. I think OBR should be a deployment tool only.
That would be fine, but at present there's no connection in the OBR interface between the Resources consumed and exposed and what actually gets deployed -- the actual Bundle instances. OBR talks in Resources, which are obviously related to Bundles, but, as I've made much noise about here, jumping back and forth between the two is not well supported. Are you suggesting removing the "start" flag from the OBR Resolver? > Imagine some tool that allowed you to use OBR to deploy a resolved > set of bundles and assign a name to that resolved set of > bundles. Then you could use this tool to start/stop/uninstall that > named set of bundles, for example. That's exactly what I need: Some way to identify the transitive closure of the bundles involved in a deployment. I don't care whether the bundle was already installed or if it just got downloaded; I want to start them all, or stated alternately, make sure they are all marked to be started. But now we're talking again about hypothetical future facilities. I arrived at the problem in this thread by more or less giving up on the other deployment approach I've described, trying to stick to the facilities available today. And now we're considering removing another facility, pushing success even further away. Here's the problem with removing the "start" flag: How does the user know which Bundles got deployed? The Resolver.getAddedResources(), Resolver.getRequiredResources(), and Resolver.getOptionalResources() methods give the set of which /Resources/ were deployed, but we can't get from a Resource to a Bundle. (Just as I've been pining for a way to get from a Bundle to a Resource.) The only way I see to map a Resource to a Bundle is to call BundleContext.getBundles(), the walk the array, looking for one that "matches" the Resource, I guess by way of symbolic name and version. Again, that seems like too much work for the /user/, trying to make these vague associations between the "world of the OSGi framework" and the "world of OBR", when under the covers these associations are already established. I'm not complaining about having to call Bundle.start() myself. I'm complaining about how I'm supposed to get the Bundle in hand. -- Steven E. Harris
