ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: [ANN] Gradle, a new build system, which uses Ivy
Date Tue, 22 Apr 2008 18:35:58 GMT

Thanks for sharing this news with us, it's very exciting to see a new build
system born, especially when it uses Ivy :-)

I'm currently reading the user guide, you've really done an excellent job!
>From what I read it seems to be a very flexible and powerful build tool. And
I really like your words on Ivy:
"Our dependency management is based on Apache Ivy, the most advanced and
powerful dependency management in the Java world."

The most advanced and powerful, nothing less :-) I guess the Ivy team and
community can be proud of it, I wish you the best!


On Tue, Apr 22, 2008 at 2:01 PM, Hans Dockter <> wrote:

> 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
> or its 50+ pages userguide:
> 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

Xavier Hanin - Independent Java Consultant

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