Thanks again for the thoughtful comments.
I think the right approach for now is to stick with the current model of
setting "organization" as the originator of the code, not the meta-data.
However in doing that we should keep this potential "packager" issue in
mind, and if it eventually looks like a new "packager" attribute is needed
(plus all the new associated conflict resolution logic), then we can add
that later down the road.
So consider this digression closed for now. I think I have enough
information to go and work on a new resolver based on these ideas... will
report back later...
Thanks,
-Archie
On Thu, Apr 3, 2008 at 12:52 AM, Xavier Hanin <[EMAIL PROTECTED]>
wrote:
> 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/
>
--
Archie L. Cobbs
