ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nascif Abousalh-Neto" <>
Subject RE: OSGi backend?
Date Wed, 07 Mar 2007 21:38:29 GMT
Thanks for the quick reply. I will give the filesystem a try.

Actually we have an in-house developed dependency management system (that I hope to replace
with Ivy) that supercedes the module descriptors in the osgi manifest; fortunately its dependency
files are easy to parse and will give me a starting point to create the ivy.xml. Unfortunately,
they won't be of any use to the community.

But if later we migrate to a true OSGi system and I have something more standard, I would
be happy to share it.


PS: I might have to create an extension anyway because in some cases I have to check for extra
metadata about the artifact before deciding it should be considered or not. Basically I would
have to look into the manifest for the presence of a flag; if it is there I would like to
evict the artifact, even if the version is a good match (and somehow provide an indication
of that in a report).

Would that be better done in a filesystem extention/replacement as a new resolver, or any
of the other kinds of ivy plugins?

-----Original Message-----
From: Xavier Hanin [] 
Sent: Wednesday, March 07, 2007 4:18 PM
Subject: Re: OSGi backend?

On 3/7/07, Nascif Abousalh-Neto <> wrote:
> Hi everybody,
> In my company we have a jar repository that implements the OSGi spec. 
> It is basically a large directory with the same structure you would 
> find under the Eclipse IDE "plugins" directory. Each of our jar files 
> is stored as an Eclipse plugin, or as an OSGi bundle.
> From my first reading of the  Ivy documentation, I believe I would be 
> able to just configure a filesystem resolver to point to the 
> repository with the appropriate pattern. But just out of curiosity, I 
> thought I would ask to see if anybody has already implemented it since 
> it and/or has suggestions on a different approach.

I think using a filesystem resolver should be fine. Note that if you want to use transitive
dependencies, you will have either to write ivy files for your bundles, or write a custom
parser able to parse osgi manifest as a module descriptor. This way to go is more interesting
IMO, because this is something that could be shared with the community. I'd be glad to help
to write such a parser. Another thing that may cause some troubles is that OSGi bundles do
not separate the organization and module name concepts.
Everything is in the bundle symbolic name. The easiest solution I see to this problem is to
consider the part of the symbolic name before the last dot to be the organisation, and the
remaining part the name. But this is only a suggestion.

- Xavier

>   Nascif

View raw message