One last question.... what purpose does the "organization" attribute really
serve anyway?
Is it only to allow for two different organizations to create modules with
the same name?
If so, I wonder if that ability is really needed. Look at the RPM namespace
for example. There are lots more RPMs in the world than than there are Java
projects, yet a flat namespace works just fine.
For example, when people refer to "jakarta-commons-lang" or "hibernate" you
generally know what they're talking about.
Maybe we should just get rid of it :-)
Just a thought.
-Archie
On Thu, Apr 3, 2008 at 8:39 AM, Archie Cobbs <[EMAIL PROTECTED]> wrote:
> 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
>
--
Archie L. Cobbs
