ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Add maven2 resolver?
Date Sun, 10 Feb 2008 08:04:10 GMT
On Feb 9, 2008 11:45 AM, Nicolas Lalevée <>

> Le 9 févr. 08 à 08:56, Xavier Hanin a écrit :
> > On Feb 8, 2008 11:01 PM, Nicolas Lalevée <
> > >
> > wrote:
> >
> >>
> >> Le 8 févr. 08 à 21:29, Adrian Sandor a écrit :
> >>
> >>> Hi, IMHO it would be much better to build a clean, well-organized
> >>> and reliable ivy repository instead of supporting that maven
> >>> garbage. By the way, why was IvyRep abandoned? I think that would be
> >>> the best solution, to have an official ivy rep., ideally containing
> >>> artifacts too.
> >>> I have nothing against [better] supporting maven reps for those who
> >>> prefer it, but I don't see why it should have a higher priority than
> >>> supporting an ivy rep.
> >>> Anyway, I've never used maven (and from what I read about it, I
> >>> avoided a world of suffering), and during the few minutes I spent
> >>> with the ibiblio resolver before ditching it, I found these main
> >>> problems:
> >>> - bad org names
> >>> - very old versions for some modules
> >>> - source and javadoc artifacts not supported (except by IvyDE)
> >>> Therefore the only solution was to manually build an "enterprise
> >>> repository" from scratch.
> >>
> >> Well, to build a "entreprise repository", you will need some
> >> "entreprise maintainers". And looking at the number of artifacts
> >> available on ibiblio, for me it is a kind of magic to have Ivy
> >> support
> >> maven repositories. And we have to admit that maven is more popular
> >> than Ivy, so people will still continue to publish maven artifacts,
> >> even non maven-built projects as Lucene.
> >
> > Agreed, this is a big advantage of leveraging maven 2 repo.
> >
> >>
> >>
> >> And on the contrary, we could imagine to have some ivy.xml just next
> >> to the pom.xml on the maven repositories, so we could have a IvyRep2
> >> with not that much effort from the developer (non necessarily ivy
> >> ones) community.
> >
> > Yes, but even maintaining ivy files require a strong community if we
> > want to
> > have good quality metadata. That's what we tried with Ivyrep, while
> > Ivy was
> > being sponsored by Jayasoft. But it was just too much work compared
> > to the
> > result on investment. I still think that implementing a good maven 2
> > compatibility is less work than trying to build our own clean
> > repository,
> > and it helps users to migrate from maven 2 too. So I still think
> > having a
> > good maven 2 compatibility is mandatory for Ivy 2 final. Once we'll
> > have a
> > large user community or some sponsorship, we will probably
> > reconsider the
> > case of public official Ivy repository.
> >
> Yes, I totally agree, I was just considering adding the possibility to
> the maven2 resolver to also try to look for an ivy.xml just next to
> the pom.xml (I haven't looked to the technical consequences though).

Technically this is very simple in Ivy, and it just had a GET.

> Then the maven2 community could also be an Ivy community. So the
> Ivyrep Adrian is looking for could be nothing more than the ibiblio one.

As Adrian says, to have something really clean, you need a separate
repository, because of many bad things in maven repo which can't be fixed
such as bad org names (for commons modules for instance). Another problem of
reusing the same repo and adding ivy files is that you then have a public
repo where revision gets updated, which breaks reproducibility (when someone
add a maven module without ivy.xml, and ivy.xml is added later).

If we really want to provide a clean Ivy repository, I see a better way:
leverage the install mechanism with namespaces and other stuff like that to
create an Ivy repo from maven 2 one, and sync them over night or something
like that. We'd need validation by a community of users to make sure the
sync doesn't introduce bad things such as bad org names. We'd also need a
policy for updating bad metadata (because we can't ensure nothing we'll ever
be wrong), and this would probably require new features in Ivy (this kind of
thing has already been discussed on ivy-dev@i.a.o list in the very beginning
of Ivy live at incubator if I remember well). But this is not easy to
achieve, and require a good amount of work. And this kind of work require
either a strong enough community, or a kind of sponsorship.


> Nicolas
Xavier Hanin - Independent Java Consultant

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