ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@hibnet.org>
Subject Re: OSGI and IVY
Date Wed, 21 Jul 2010 13:07:19 GMT
On Wednesday 21 July 2010 03:28:58 Archie Cobbs wrote:
> On Tue, Jul 20, 2010 at 12:53 PM, Shawn Castrianni <
>
> Shawn.Castrianni@halliburton.com> 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

Mime
View raw message