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 jfoobar.zip 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.
Adrian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
