|
»
»
»
»
« Return to Thread: Generic build system?
Re: Generic build system?
by hdockter
::
Rate this Message:
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
http://www.gradle.org
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
http://www.gradle.org
« Return to Thread: Generic build system?
| Free Forum Powered by Nabble | Forum Help |
