On Apr 11, 2007, at 4:29 PM, Steven E. Harris wrote:
I see no mention in the OSGi R4 specification that precludes two bundles with the same symbolic name but different versions from coexisting as installed in the same framework. In fact, enabling such coexistence seems to be one of the goals of OSGi.
Well, you can specify a singleton bundle, then you can only have one version, but otherwise you are correct.
Still, I'm confused by how one chooses between Bundle.update(), feeding in a new bundle with a new version to replace an existing bundle with the same symbolic name, and BundleContext.installBundle(), also supplying a new bundle with a new version, but leaving a currently installed bundle with the same symbolic name in place.
Conceptually you should use Bundle.update() to change a bundle to a newer version of itself; however, there is no requirement to use it this way. I have had an idea that I always wanted to prototype about making a more sophisticated bundle update mechanism that allowed you to replace a bundle with a completely different bundle as part of its update process, so that you could do things like transform is private data for the new version. This intermediate bundle could transform the private data area then instigate the final update to the actual updated version of the original bundle. Generally speaking, update allows a bundle to become another bundle.
My interest is in enabling bundle management in a client that downloads "opaque" bundles from a server. By opaque, I mean that the client doesn't know the symbolic name and version of the bundles it downloads, but would like to install them appropriately -- updating in cases where a bundle with the same symbolic name already exists, and just installing when such a similar bundle is not already installed. Doing this properly seems to rely upon being able to discover the newly downloaded bundle's symbolic name and version /before/ trying to install it, as installing it may clash with an existing bundle, or miss an opportunity to update an existing bundle. Is this goal best delegated to OBR? I see several of these problems solved there, such as figuring out whether an installed bundle is updatable, but I don't think it addresses the problem of not knowing a priori the symbolic name and version of a bundle one wants to install.
I am not exactly sure what the issue is. To do discovery, you generally need some metadata describing the bundles that are available for install. For OBR, this is the repository.xml file. It seems like you want your metadata to just be a list of URLs to bundle JAR files, which is why you are unable to check for overlap. If you assume your metadata includes the symbolic name and version of the bundle, then it becomes quite easy to check for overlap. This is what OBR does, effectively it uses symbolic name/version as the primary key for both the OBR database as well as the set of installed bundles.
-> richard
-- Steven E. Harris _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
