ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Sandor <>
Subject Re: Open source ivy files project?
Date Thu, 03 Apr 2008 05:13:12 GMT
Archie Cobbs wrote:
> Thinking about this more, I think it boils down to this question: do we
> assume the entity creating software jfoobar is the same as the entity
> creating the ivy.xml file for jfoobar?
> In an ideal world, yes I agree: this would be true, and then there is no
> question who the "organization" is.
> However, in the real world, I don't see many projects shipping ivy.xml files
> in their distributions....
> For Ivy to get more popular and usable, there has to be a way for people to
> just "plug & play" into an existing ivy distribution network of some kind
> (like the one I'm proposing). Like CPAN is for perl, etc.
> But for such networks to exist, Ivy has to support "3rd party" packaging.
> Otherwise, there will have to be a "one true source" of ivy.xml files... and
> who will that be? I don't see anyone stepping up to the plate at the moment.
> And for 3rd party packaging to work (see below), we need to be able to
> separate the "producing" organization from the "packaging" organization.
> So you either have to make "organization" the packager.. or, add another
> resolution dimension ("packager"?)
> -Archie

I see your point, and I have some comments:
- The org. and module don't have to be unique *in the whole universe*, 
but just in each repository; different repositories can have the same 
module with the same org. but different packagers (and probably 
different ivy descriptors)
- There may be 2 modules with the exact same name but different 
organizations (creators); if the packager is the same, then how can you 
distinguish them, other than by the org.?
- Anyway, I think it's a good idea to add an optional packager 
attribute, and perhaps a packaging version (so that you can fix a 
problem in the descriptor without overwriting it and without changing 
the module revision), then we should think about how ivy will choose a 
module when it's available with different packagers

Btw, I'm not an ivy developer, but just a tiny contributor.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message