ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Archie Cobbs" <arc...@dellroad.org>
Subject Re: Open source ivy files project?
Date Thu, 03 Apr 2008 20:20:18 GMT
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 <archie@dellroad.org> 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 <xavier.hanin@gmail.com>
> wrote:
>
> > On Thu, Apr 3, 2008 at 7:13 AM, Adrian Sandor <aditsu@gmail.com> 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: dev-unsubscribe@ant.apache.org
> > > For additional commands, e-mail: dev-help@ant.apache.org
> > >
> > >
> >
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
> >
>
>
>
> --
> Archie L. Cobbs
>



-- 
Archie L. Cobbs

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message