We are very excited to announce Gradle, a new build system.
We announce it on this list, as Gradle uses Ivy for its dependency
management.
To learn more about Gradle, have a look at http://www.gradle.org
or its 50+ pages userguide: http://gradle.org/userguide/release/
userguide.pdf
The rest of this posting is dedicated to Ivy and dependency
management in general.
Before I've started to develop Gradle I had only a faint idea about
Ivy. I had been using Maven for years, and I had started to develop a
new build system out of this not very satisfying experience. When I
was starting to develop the dependency management, I had a closer
look at Ivy and I decided to give it a try. I'm so happy that this
turned out to be a very good decision.
- Gradle integrates deeply with Ivy via its API. Although I guess not
many projects use Ivy via the API, the API has been almost perfect to
our needs. There was not a single ugly hack necessary, to make Ivy do
what Gradle needs. It was possible to introduce new concepts for
dependency management by using Ivy as a low level API. This says a
lot of the quality of Ivy's code base (and I guess about the virtues
of test driven development). I'm very impressed.
- Ivy has taught me a lot about the problem space of dependency
management (although I have considered myself as an experienced
build master for enterprise projects). The unit for measuring the
differences to Maven in solving this problem space is light-years :).
I'm still overwhelmed by the complexity of Ivy. Although I've worked
a lot with Ivy in the last 6 months I still consider myself being
just on the intermediate level. I'm still confused or unknowing about
the role of an IvyNode in the resolve process, the resolve process
details themselves, the usage of IvyContext, and many more things.
It would be terrific if an Ivy code expert would join me for a code
review on Gradle's usage of Ivy.
Ivy is so tremendously superior to the Maven2 dependency management,
and yet it seems Maven2 is taking up more and more of the market
share. Ivy scales up extremely well. What I think is missing is an
EasyIvy which does pretty much what Maven does. But without locking
you in, into this simplified approach. Gradle is offering exactly
this (and many other things).
Another thing that Gradle adds on top of Ivy are Client Modules. They
enable support for transitive dependency management without the need
for pom.xml or ivy.xml files. Thanks to Ivy's flexible repository
layout patterns, you can thus easily use a flat project folder (under
version control) containing the libraries and do something like:
dependencies {
clientModule('compile', ":groovy-all:1.5.5") {
dependency(":commons-cli:1.0")
clientModule(":ant:1.7.0") {
dependencies(":ant-junit:1.7.0:", ":ant-
launcher:1.7.0")
}
}
}
No ivy.xml necessary. No organisation id. No remote repositories. You
can check out the project and build it without the need to download
anything and yet have support for transitive dependency management.
It is a choice we give to our users. It is another part of the
EasyIvy idea.
There have been only a few things I was missing. The Ivy API does not
provide functionality for getting a list of files pointing to the
local location of the resolved libraries. I had to do a copy'n'paste
from Ivy's Ant cachepath task. On first sight, the same seems to be
true for doing reports. I need to have a close look on this topic.
I think it is an exciting time for build systems. Gradle is written
in Groovy and the build scripts are in Groovy. We think internal
DSL's based on a general purpose language like Groovy are better
suited for writing build scripts than XML. This is a different
discussion though.
Thanks a lot for Ivy
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
