ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: Advice for managing large-scale OSGI repository for data analysis
Date Mon, 29 Aug 2011 21:25:23 GMT

Le 29 août 2011 à 21:12, Marcel Bruch a écrit :

> Hi ivy-users,
> we are currently setting up a large code repository for OSGI bundles. Goal of this work
is to create recommendations models for Eclipse Code Recommenders intelligent code completion,
code search, and extdocs platform (see and
for details). The OSGI bundles will be collected from public available Eclipse Update Sites
and should be stored locally using a Maven/Ivy like directory structure. After the sites have
been copied, several analyses will be run to extract information such as frequent usage patterns,
common code snippets etc.
> I just learned that since 2.3. Ivy has support for dealing with OSGI dependencies such
as import packages etc. which is really big news! Since documentation is a bit rare yet, I'd
like to ask you for little information what can be done with Ivy 2.3:
> 1. Is it supported to copy/mirror an Eclipse P2 repository into a local Ivy repository?

I have successfully made Ivy read a Eclipse P2 repository in order to download its jars, like
any other jar repository, but nothing more. The pieces should be there to do the complete
copy chain though.

> 2. Is there a simply way to create an Ivy file from an existing OSGI-bundle manifest?

There's an Ant task:

> 3. How well is resolving OSGI dependencies supported? Are there any known limitations
I should be aware?

Here is a complete view of how OSGi dependencies are mapped to Ivy ones:
Thus you can find which OSGi metadata is supported and which is not.

Then about the resolve algorithm: compute the best set of jars considering the "requirements"
and the availables jars. I think it should work on most cases (I hope, it's experimental,
not well tested).
There 2 cases Ivy won't be able to resolve as smart an a pure OSGi engine:
 - having several different versions of the same jar which live in the same OSGi environment,
Ivy won't support that (ever, unless a tremendous refactoring in Ivy).
- an import package has to be resolved against an implementation. Ivy don't do anything smart,
it takes the first which fits. And if the choice makes the resolve fail (because by transitivity
there's some conflict), it won't be able to trackback to that choice and try another. It will
just fail. It might be quite complicated to make Ivy support that.

Then any feedback on some successful (or unsuccessful, but let's be optimistic :) ) use of
OSGi features of Ivy will be more than welcomed.


View raw message