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
On Wed, Apr 2, 2008 at 12:22 PM, Archie Cobbs <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 2, 2008 at 11:40 AM, Xavier Hanin <[EMAIL PROTECTED]>
> 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?
>
> 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 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.
>
> -Archie
>
> --
> Archie L. Cobbs
>
--
Archie L. Cobbs
