ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: [ANN] Gradle, a new build system, which uses Ivy
Date Wed, 23 Apr 2008 10:26:33 GMT
Le mardi 22 avril 2008, Hans Dockter a écrit :
> 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.

Here you introduced a new vocabulary to define dependencies. I don't see any 
reason to do so. The ivy.xml are not harder or simpler to read or write than 
the language to introduce. And you loose every work on tools which have been 
develop to manage ivy.xml files, like IvyDE and Ivy RoundUp Repository.

Althoutgh Gradle seems interesting by its integration with Ant tasks. And then 
we should be able to use the Ivy Ant tasks.


> 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

View raw message