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