ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Dockter <>
Subject Re: Generic build system?
Date Sat, 12 Jul 2008 13:52:02 GMT
Hi Jean-Louis,

On Jul 12, 2008, at 12:44 PM, Jean-Louis Boudart wrote:

> Using a script language like groovy for build system sounds  
> interesting.
> Doing complexe things will be easier, using a groovy than doing it in
> Ant-XML.
> What i doesn't like in gradle is the "new syntax" for dependencies
> declaration, 'cause you can't use all the stuff behind ivy (like the
> eclipse plugin IvyDe) or you must configure application tu use   
> ivy.xml
> generated by  gradle. :/

The whole point of Gradle is to offer more power and freedom.  
Configuring the dependencies in Groovy offers more possibilities. One  
use case from the Gradle build itself:

Gradle ships with its own version of Groovy which is part of the  
dependency declaration. On our CI server we have one build  
configuration were we build and test Gradle with the latest Groovy.  
To do this we just pass an argument with the URL to the Groovy jar we  
are interested. If this argument is set, we download the jar as part  
of the build script and add it to our dependencies instead of the  
default jar. This is very quick solution to a problem we had.  
Additionally we have introduced new semantic concepts on top of Ivy  
like client modules. You could not use them via XML.

But of course, as you have mentioned, it also has disadvantages not  
to use the ivy.xml. It would be pretty easy to enhance Gradle to also  
accept ivy.xml's and ivysettings.xml's. It should even be easy to mix  
both forms of declarations. There are just other things which have a  
higher priority for us at the moment. If this is your biggest worry:  
Why not contributing this to Gradle ;) It would definitely take less  
time than creating an Ant based build by convention approach.

I think one big problem with Ant is that is had to introduce many  
general purpose language elements in its XML DSL to deal with complex  
builds. Those constructs are Ant specific, therefore have a high  
learning curve. And yet they are a pale imitation (thanks for this  
phrase, Russel ;)) of what a full blown OO language has to offer.

> What about integration with continuous integration?

This is no problem for Gradle. With the help of the Gradle Wrapper  
you can run Gradle builds on any CI server without the need to have  
Gradle installed there. See the Gradle user's guide.

- Hans

Hans Dockter
Gradle Project lead

View raw message