On Thu, Apr 3, 2008 at 10:20 PM, Archie Cobbs <[EMAIL PROTECTED]> wrote:
> 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?
Yes, mainly.
>
>
> 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.
First I'm not sure of the proportion, if you take into account all privately
developed java projects.
Second, a flat namespace would involve a change in the structure to store
repositories, because some filesystems don't perform very well when you have
a very large number of directories in only one directory.
That being said, I already wondered if by using the package names convention
we couldn't actually get rid of organization. After all, that's what OSGi
does. But this is a big change in Ivy, and I'm not sure it's worth it.
Xavier
>
>
> 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
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
