On Wednesday 21 July 2010 03:28:58 Archie Cobbs wrote: > On Tue, Jul 20, 2010 at 12:53 PM, Shawn Castrianni < > > [email protected]> wrote: > > Has anybody researched the relationship between OSGI and IVY? I have a > > large build system running on IVY and is working great. However, > > development wants to move towards an OSGI runtime framework which impacts > > how the modules are built. I am trying to figure out how I can merge in > > OSGI bundle creation with my IVY based build system. > > > > I am finding that the dependency mechanism and publish mechanism in OSGI > > is fighting with the same concepts in IVY. Therefore, I am not making > > any progress on this OSGI project. > > I'm curious about this too but haven't acquired any wisdom on the answer > yet. > > There is this concept of OBR - OSGi bundle repository. For example, > Oscar<http://oscar-osgi.sourceforge.net/>and the OSGi > site has one <http://www.osgi.org/Repository/HomePage>. I'm not sure yet if > this OBR concept is just for local stuff (it says "federated") or if there > is going to be some kind of master/top authority from which to delegate, > i.e., like how DNS works (in fact, no reason the DNS system could be used > as a way to locate repositories, e.g., "_osgibundlerepository.domain.com").
On the repository side, OBR means having a single xml descriptor listing every bundles and their OSGi properties. In that descriptor can be also reference other url based repositories. Just like the ivysettings. -- general reply to this thread -- OBR seems to me the most interesting solution to dependencies management (only in the java world though). OBR not only specify the repository xml descriptor, the draft spec I read (I haven't heard it has been near final) also specify a client API and how the resolver would behave. As some of you have rightly spotted, an OSGi's manifest is only meant to specify runtime dependencies. Whereas Ivy can do more with configurations. And as spotted to OSGi's Import/Export-Package is more modularity friendly than Ivy's organisation/module. The OBR draft spec seems to fill that gap by relying only on OSGi's Manifests on the repository side. But on the client side we would launch a resolve with a "query". So in a pure OSGi solution, we would rely on a Manifest.MF which specify a dependency on javax.servet, and you actually get jetty's or tomcat's or other obscure implementation for testing. In a pure Ivy solution, we would rely on an ivy.xml which specify a dependency on jetty, but once published it cannot be used with tomcat without some dependency overriding. Using an OBR client, we would have a Manifest.MF which specify a dependency on javax.servet to be used while we will publish our jar in a repo, but we would resolve dependencies for testing by querying for jetty's impl. I haven't seem though an OBR client implementation which offer a simple way of dependency declaration. There are only Java client API, not a descriptor ala ivy.xml or pom.xml or Manifest.MF. And here comes Bushel [1]. The idea is to have an ivy.xml which overrides a Manifest.MF. The Manifest.MF would define the API dependencies, seen as the runtimes ones. And then in the ivy.xml we can see the runtime dependencies from the Manifest.MF and extend them to specify which actual implementation we want behind some API. Bushel doesn't have the OBR client API but can read a OBR xml descriptor. One big caveat of that solution is that it is not clear to me if it is even possible to to generate the Manifest.MF from tools like bnd, as manifests can be quite complicated to maintain manually. Another point I am not sure about, is if Bushel can resolve complicated dependencies. It is relying on Ivy and Ivy has only one kind of dependency whereas there are several ones in OSGi (see introduction of [2]). I have to admit I don't know Sigil much, but as far as I could tell when I look into it is that it doesn't support that kind of overriding like in Bushel. To clear this out: as all of you I haved tried to find the best way to fill the gap between Ivy and OSGi. I explain here that I find bushel the best fit. But I may not be quite objective here as I did wrote some big part of Bushel. ;) Nicolas [1] http://code.google.com/p/bushel/ [2] http://code.google.com/p/bushel/wiki/IvyOsgiMapping
