ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: Open source ivy files project?
Date Thu, 03 Apr 2008 06:40:06 GMT
On Wed, Apr 2, 2008 at 7:22 PM, Archie Cobbs <archie@dellroad.org> wrote:

> On Wed, Apr 2, 2008 at 11:40 AM, Xavier Hanin <xavier.hanin@gmail.com>
> wrote:
>
> > >   2. What happens in ivy when two different repositories in your
> > >   settings publish the same organization, name, and version of a
> module?
> >
> > It depends on your settings, but most probably the first one will be
> used
> > and the second one ignored. The couple organization#module MUST identify
> a
> > module uniquely. A module's revision is identified by
> organization#module
> > +
> > revision + extra attributes if any. But for a public repository I
> wouldn't
> > use extra attributes, so sticking with pure organization#module;revision
> > as
> > identifier should be a good choice.
> >
>
> OK, so organization+module MUST be unique... but how do you expect to
> enforce your "MUST"?? Are you in control of all the Ivy repositories of
> the
> world? Or, is everyone expected to create their own private repository and
> never share?

If you follow the package name convention, which in turn should follow the
returned domain name as basis, you should have unique names thanks to domain
unicity (if no project from the same domain use the same sub package name.
You can't really be sure of this, but I think it's up to the user using
multiple repositories to make sure there is no outstanding namespace
conflict between repositories he uses, and use Ivy namespace feature if
needed to clear these namespaces and unicity issues.

>
>
> I think the "organization" attribute has to refer to the ivy module
> packager, not the originator of the code. Otherwise, the system seems
> totally broken to me.

The problem with that approach is that you end up with several packagers of
module which actually are the same code. Then you don't have any conflict
management between those modules, which for Ivy are different. And then you
run into much more troubles.

>
>
> The only way you can expect organization+module to be unique is to require
> either:
>
>   1. Only the Foo organization can ever publish an ivy module with
>   organization="foo"; OR
>   2. There is some global authority designating who is the one true
>   authorized group that is allowed to put organization="foo" in their
> ivy.xml
>   files
>
> And option #2 is not an option unless you want to get into the business of
> ivy dictatorship.
>
> Examples: #1 is approach taken by Java package naming; #2 is approach
> taken
> by DNS domain system.
>
> Let's take an example, e.g. Hibernate. If someone (other than the
> Hibernate
> developers) creates an ivy module with organization="hibernate.org"
> name="hibernate" then a priori this module is going to be incompatible
> with
> the same thing created by someone else.
>
> Since there's no one true Ivy repository (RIP ivyrep) this is bound to
> happen: all the ivy repositories out there are going to be incompatible.
> And
> there's no clear way for me to specify that "I'd like the Hibernate module
> from repository A, but I'd like the Spring module from repository B".
>
> I'd suggest Ivy should encourage a decentralized model that is more
> compatible with the reality of the Internet. To me this seems like a
> pretty
> fundamental issue that needs to be examined for Ivy to succeed.

I agree, I really believe in a decentralized model, but you can't use module
ids related to the author of metadata only, due to conflict management
issues as I said above.

Xavier

>
>
> -Archie
>
> --
> Archie L. Cobbs
>



-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

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