I saw in the 1.0 release announcement that you guys have ditched Ivy for your own code that integrations with Ivy/Maven repos.
I have a love/hate relationship with Ivy–it is not Maven (which is good), and generally does the right thing, but is finicky at times. And I’ve glanced at the Ivy codebase just enough to get the impression it will always be this way.
Given you guys have a “basically Ivy but better” replacement, do you think there is any chance of the code you wrote becoming Ivy 2.0?
Er, right, Ivy is already on 2.x…Ivy 3.0 then. Sorry. 
What exactly do you mean by “becoming Ivy 3.0”? We do intend to make our dependency management more independent from the rest of Gradle. We don’t intend to move forward with Ivy concepts or code. Of course we will keep supporting Ivy repositories.
We do intend to make our dependency management more independent from the rest of Gradle.
Cool!
We don’t intend to move forward with Ivy concepts or code. Of course we will keep supporting Ivy repositories.
Understood you don’t want to move forward with code from Ivy itself.
But I was just musing that, since you’ll keep supporting Ivy repositories, with its various patterns/confs/etc., I was thinking that perhaps your codebase would be a good “clean slate” start for an Ivy rewrite or “3.0”.
Ivy was always (AFAIK) supposed to be a generic/build-tool-independent dependency library, but if you guys had to give up using it (I assume because the functionality/integration was a pita), and built something better, it just seems like your “better Ivy” could be the “new and improved Ivy” for all users of Ivy, not just those who are lucky enough to benefit from your re-implementation by using gradle.
Although perhaps the Ivy 2.x codebase is not as bad or abandoned as I’d imagined…
No Ivy 3.0, sorry. Our future plans are very different.
Our future plans are very different.
Interesting; apologies if I’m making you rehash something that’s on a published roadmap, but you’ve piqued my interest…what are your future plans that are so different?
If you’re planning on making your dependency code more independent of gradle (which is great), won’t you essentially be making an ivy competitor/replacement?
(This would be just with me…I use a variety of build tools, haven’t had a chance to use gradle yet, but I think Ivy made a strong case that having a “only dependencies” file, separate from the build file, was a nice way to go, as then your IDE (e.g. IvyDE) could pull in the ivy.xml and not have to know whether you were using buildr or gradle or sbt or ant or whatever. Given how much of a pita Eclipse plugins are, it makes sense to write that just once, I think.)
(Generating .classpath files is a great start, but then you can’t “resolve references in workspace” which is, IMO, a killer feature of an Eclipse plugin like m2e/IvyDE.)
Gradle 1.0 already has a number of features that wouldn’t have been possible with Ivy (see the documentation). Likewise, we don’t support all Ivy features. The differences will only grow in the future, both in terms of features and philosophy.
If you’re planning on making your dependency code more independent of gradle (which is great), won’t you essentially be making an ivy competitor/replacement?
Not really. We are going to provide an API, not a turn-key solution.