On 7/11/07, Jing Xue <[EMAIL PROTECTED]> wrote:
Quoting Xavier Hanin <[EMAIL PROTECTED]>: > 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 mvnrepository.com 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! Xavier
What do you think? My 2 cents. 8-) Thanks. -- Jing > > Xavier
-- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://incubator.apache.org/ivy/ http://www.xoocode.org/
