ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Open source ivy files project?
Date Thu, 17 Apr 2008 06:45:46 GMT
On Wed, Apr 16, 2008 at 9:48 PM, Archie Cobbs <> wrote:

> On Wed, Apr 16, 2008 at 1:45 AM, Xavier Hanin <>
> wrote:
> > On Wed, Apr 16, 2008 at 8:37 AM, Gilles Scokart <>
> > wrote:
> > > Maven has naming conventions [1], [2].
> > >
> > > The problem is that those conventions apeared  with maven 2.  maven 1
> > > didn't had this and the maven repository actully contains an export of
> > > the maven 1 repository.  That's why the naming convention didn't
> > > seemed to be always followed.
> > >
> > > Note however, that they give advices to fix that [3].
> >
> > The problem is that the repository is cluttered with old naming
> > conventions,
> > which make it sometimes difficult for users to find their way out:
> >
> >
> >
> >
> >
> By the way, I've been thinking about this problem as well.
> Since Ivy RoundUp builds its repository using ant, it would be easy to add
> "meta-data meta-data" that would handle things like backward-compatible
> aliases for organisation names.
> E.g., if a Hibernate is officially known under org="org.hibernate" but
> unofficially with org="hibernate" and org="net.sf.hibernate", then we
> could
> add a file in src/modules/org.hibernate/aliases.xml:
>  <aliases>
>    <alias org="hibernate"/>
>    <alias org="net.sf.hibernate"/>
>  </aliases>
> Then the build would automatically create copies of the module under both
> locations in the repo.

IMHO, it's what should be avoided. For me the perfect repository has no
duplication, each module can be found in only one place, and metadata is
perfect :-) Obviously sometime you will have modules changing of
organization in their lifetime, but it should reflect a real change, not a
change in the way you write the metadata.

That's why I think using the package name convention for the organization
makes a lot of sense. We can even actually follow the package used in the
library, so that there is no ambiguity. we could even add a tool checking
that you can't add a module in an organization which doesn't actually
reflect the package name used in the jar (for modules providing a jar only).
Then the only remaining question is where to stop in the org name (I mean,
at which dot in the package name), and which name to use with the module

BTW, I was also thinking about the repository quality and I think a good way
to achieve a good quality is to check what you put in the repository.
Automatic checks can perform some validation (like org name as I said
earlier, metadata consistency, all dependencies available, ...), and
community check others. To perform these checks, a staging area in the repo
may be interesting: contributors commit new modules metadata in the staging
area only, then these metadata are copied to the official repo when some
checks have been performed. With a large enough community, you could have a
vote system, as soon as the module gets 3 positive votes from a recognized
set of people it goes to official repo.


> Actually, an even simpler way would be with a symlink checked into SVN...
> You could do similar things with the module name as well of course.
> In any case, the larger point is that the RoundUp project could provide
> ways
> to help these kinds of issues.
> -Archie
> --
> Archie L. Cobbs

Xavier Hanin - Independent Java Consultant

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