On Thu, Apr 3, 2008 at 7:13 AM, Adrian Sandor <[EMAIL PROTECTED]> wrote:
> 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
This is a tough problem when you have to deal with conflict management in
the mean time. That's why I wouldn't put this choice in the tool
responsibility, but rather in the user responsibility: when choosing to pick
up modules from several repositories, the user has to choose the main trust
source, by putting it at first position in the chain for instance. With Ivy
namespace support, and per module resolver settings, you really have very
good control over the set of repositories you want to use.
BTW, I think the worst thing for Ivy would be to have many different
repositories hosting the same modules with different metadata. I clearly
don't believe in a centralized repository, but I think you'll have mainly
two cases:
- modules for which the original author don't publish metadata, in which
case if you really start your initiative now, "Ivy Roundup" will probably be
the de facto official source for this kind of modules.
- modules for which the original author publishes metadata, in which case I
don't think other repositories will have to publish different metadata,
except in some cases where a community really see a fix for the metadata. In
this case, once again I think there is good chance to have only one main
community as de facto official source, most probably the same as for the
first option
Xavier
>
> 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]
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
