ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: status of official ivy repo?
Date Wed, 11 Jul 2007 16:17:07 GMT
On 7/11/07, Jing Xue <> wrote:
> Quoting Xavier Hanin <>:
> > This is a good question! The last version of Ivy defaults to use the
> maven 2
> > repository instead of ivyrep. But I still think ivy files are more
> flexible
> > than maven 2 poms (mainly thanks to configurations), so it would be
> > interesting to have ivy files for some modules, and poms for the rest.
> To me, the ivy dependency language is more expressive and powerful,
> especially when combined with carefully planned configurations, as you
> pointed out. And the power would be compounded if most modules use
> (responsibly crafted) ivy.xmls rather than poms to describe their
> dependencies.
> Take a library as basic as commons-logging for an example. In its pom,
> it depends on avalon-framework, avalon's logkit, and a few other
> things, while depending on your logging configuration usually only
> part of those are actually _required_ at neither compile-time nor
> run-time. It's no wonder applications using maven typically have a
> bloated lib directory - especially when they use big "conglomerates"
> like spring or hibernate. OK, I'll stop before this turns into
> maven-bashing. 8-)

I agree, that's one of the reason why I still prefer Ivy over maven
dependency management. But having a huge repository like maven has is a real
asset, that's why it's also important to be able to leverage the maven repo.
And if we can put Ivy files only when maven poms are not good enough, it's
much less work for the Ivy community, and still very interesting IMO.

> Then
> > when using Ivy you would by default use Ivy file when present, and pom
> when
> > there is no ivy file. This requires to have the same namespace (apache
> > commons modules in commons-xxx organization for instance, and use of
> dots in
> > organizations names). But it could be useful, especially if we provide a
> > task to publish to a maven 2 repo (including conversion of ivy file to a
> > pom). Then it would be pretty easy for Ivy powered projects to publish
> to
> > the maven 2 repo without loosing the quality of their metadata. There's
> > already an issue asking for the creation of a ivytopom task, with that
> we
> > wouldn't be too far from what we need. The other part is convince maven
> > people to accept ivy files in their repository... I can start a
> discussion
> > about that. The final point is that it wouldn't be possible IMO to
> publish a
> > module with several artifacts (except source and javadoc).
> It'd be great if the repository can be unified.  On the other hand,
> ivy maintaining its own repository, or more importantly, its own
> repository format, can be rather advantageous, too.  One thing off the
> top of my head is there can be formal definition for dynamic version
> resolving queries, rather than having to rely on parsing ibiblio html
> (that's how ivy does it now, if I'm not mistaken?)

Yes, that's how Ivy does it now, but there are plans to take advantage of
the maven metadata.xml already present. What I don't like with maven
metadata is that you absolutely need a unique process to update it, to avoid
concurrency problems. So I think it requires some kind of repository
service, instead of using regular file based repositories (and I include
file systems with remote access like ftp, scp, webdav, ...). And if you have
a real repository service, I think it's better to delegate the query
execution to the repository service, instead of providing an access to a
metadata.xml file with a list of revisions. But this is much more work, but
still could be interesting, even on top of maven repository (like a providing service for tools instead of humans). The client
(Ivy) part would be pretty easy IMO, the more work is in the server part.
ATM I think we (the Ivy team) still need to keep focused on Ivy core, we are
not big enough to address this idea right now. But once we'll get graduated
with a rock solid 2.0 final version, hopefully we'll get more time and a
bigger community to tackle this kind of subject!


> What do you think?
> My 2 cents. 8-)
> Thanks.
> --
> Jing
> >
> > Xavier

Xavier Hanin - Independent Java Consultant

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