A big chunk of your bundle analysis already exist in a widely used OSGi tool, named BND. Most OSGi developers use it, since it is near impossible to create the metadata by hand, especially the "uses" constraint.
But before that we spoke of figuring out how a particular implementation wire up a random set of bundles. That is not predictable, nor does the OSGi spec provides an API to find out. Well, kind of... If you have the loaded class, you can ask from which bundle it came, but unfortunately the StackElement doesn't give you the Class, only the class name, which isn't enough. But I agree with you that with Jini tech and OSGi's well-defined classloading semantics one can do really cool stuff. Including getting rid of some of the more troubling Jini aspects (codebase). -- Niclas On Oct 16, 2009 8:21 PM, "Peter Firmstone" <[email protected]> wrote: Hmm, that sounds like opportunity. A dedicated codebase service has all the time in the world to burn processor cycles on analysis, as its main task is simply serving up jar files over networks. Bytecode analysis, identifies class, package and possibly module API, which can be stored with the harvested metadata in mirror objects, one for each class, package and module. Optional Package metadata could be a potential source of information too. Bundles, depend upon and export packages. Once the API is identified using bytecode analysis, fast comparison using mirror objects could identify compatibility. This could be utilised in two ways: 1. As a check of backward compatibility for modules / packages over different release versions, for substituting later compatible bundle versions, if desired. 2. When a dependency on a package only utilises a subset of that package, the actual API requirements may still be satisfied, even though different release versions of that package may not usually be interchangeable or fully compatible. A module or bundle would exist within its own classloader, in the local jvm. The packages or modules upon which it depends could be made available from other classloaders. Bundles could be uploaded to codebase services or a codebase service could retrieve the bundles from designated repository's, perform analysis, then make the bundles available in a location independent manner, to prevent codebase loss and allow for redundant codebase services. Then all one need do is to upload application bundles to the codebase server and register a service, the service and bytecode could be provided independently, the codebase service can provide entire application bytecode built on Jini services and other third party libraries. Have a look on springsource, there are many OSGi jar bundles available, these are simply jar files with Metadata. Someone's done so much hard work already, why not ride the wave? There are already support tools available to create application bundle manifests. The reason I'm considering bundles, is it reduces the number of classloaders required, one per bundle as opposed to one per package. One cannot rely on standard java Package meta data to exist in jar files. ********This doesn't require an OSGi framework.********* http://blog.springsource.com/2008/02/18/creating-osgi-bundles/ http://www.springsource.com/repository/app/bundle?query=A http://www.springsource.com/repository/app/faq >From the website: What is the SpringSource Enterprise Bundle Repository? The SpringSource Enterprise Bundle Repository is a collection of open source libraries commonly used for developing enterprise Java applications with the Spring Framework. The repository contains jar files (bundles) and library definition (".libd") files. A library defines a collection of bundles that are often used together for some purpose (e.g. the "Spring Framework" library). There are hundreds of bundles contained in the repository. The repository meets the following criteria: * Every jar file in the repository is a valid OSGi bundle. Any jar you download from the repository can be deployed as-is into an OSGi Service Platform and the SpringSource dm Server. It can also be used as a regular jar file outside of OSGi. * Every bundle and library has full version information associated with it. The package export information for a bundle contains version information, and the package import information for a bundle contains full version range compatibility information. * The repository is transitively complete. The mandatory dependencies of any bundle are guaranteed to also be in the repository. Most of the optional dependencies of any bundle in the repository will also be present. The bundles listed in any library definition are guaranteed to be in the repository. * The repository is self-consistent. Before any artefact is uploaded to the repository, we verify that it can be installed, resolved, and started in an OSGi Service Platform (using the same profile as the SpringSource dm Server) alongside all of the other bundles in the repository. * The repository can be used from Ivy and Maven based builds. Cheers, Peter. Niclas Hedhman wrote: > > On Fri, Oct 16, 2009 at 1:04 PM, Niclas Hedhman < [email protected]> wro...
