On Wed, Apr 2, 2008 at 7: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? 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/
