ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nascif Abousalh-Neto" <Nascif.AbousalhN...@sas.com>
Subject RE: OSGi backend?
Date Wed, 07 Mar 2007 22:12:09 GMT
Excellent, thanks for the tip. 

-----Original Message-----
From: Xavier Hanin [mailto:xavier.hanin@gmail.com] 
Sent: Wednesday, March 07, 2007 5:10 PM
To: ivy-user@incubator.apache.org
Subject: Re: OSGi backend?

On 3/7/07, Nascif Abousalh-Neto <Nascif.AbousalhNeto@sas.com> wrote:
>
> 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.


Note that you can provide a customm module descriptor parser and continue to use your own
format if you prefer. It depends on why you migrate away from your existing dependency management
system.

But if later we migrate to a true OSGi system and I have something more
> standard, I would be happy to share it.
>
> Thanks,
>   Nascif
>
> 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?


With a custom dependency resolver you can do it with no problem, but it might be somewhat
complex , because DependencyResolver have quite a lot of responsibilities, so it makes them
more difficult to extend / customize.
Maybe what you want could be easily achieved with a VersionMatcher: you can consider your
version with the flag as "not matching" and this should be enough.

- Xavier

-----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: Wednesday, March 07, 2007 4:18 PM
> To: ivy-user@incubator.apache.org
> Subject: Re: OSGi backend?
>
> On 3/7/07, Nascif Abousalh-Neto <Nascif.AbousalhNeto@sas.com> 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.
>
> HTH,
> - Xavier
>
> Thanks,
> >   Nascif
> >
> >
> >
>

Mime
View raw message