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-)
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?)
What do you think?
My 2 cents. 8-) Thanks. -- Jing
Xavier
