Thanks Eske,
Looks like v1.0 will be out sometime in the first half of 2010 from
their roadmap & speed of development.
Quote from user guide:
Gradle offers a variety of ways to organize your build logic. First of
all you can put your build logic directly in
the action closure of a task. If a couple of tasks share the same logic
you can extract this logic into a
method. If multiple projects of a multi-project build share some logic
you can define this method in the parent
project. If the build logic gets too complex for being properly modeled
by methods you want have an OO
Model. Gradle makes this very easy. Just drop your classes in a certain
folder and Gradle [32] automatically
compiles them and puts them in the classpath of your build script.
Gradle offers you a variety of ways of organizing your build logic. You
can choose what is right for your
domain and find the right balance between unnecessary indirections, and
avoiding redundancy and a hard to
maintain code base. It is our experience that even very complex custom
build logic is rarely shared between
different builds. Other build tools enforce a separation of this build
logic into a separate project. Gradle
spares you this unnecessary overhead and indirection.
Definitely worth keeping an eye on. When v1.0 arrives I'll look into
whether it'd help lower the barrier to entry for new River developers.
Cheers,
Peter.
Eske Sort wrote:
I have and I'm exited :) It seems a very nice build tool. It is very
flexible and allows you to do all sorts of things in an easy manner (think
Ant) while giving you the build-by-convention offered by Maven. It does not
enforce the convention however (as Maven does more or less).
Given Gradle's flexibility my guess is it would fit nicely with River.
However, I don't know much about how River is organised source-wise so I
could be mistaken.
One thing to be aware is that Gradle is currently at version 0.7 with 0.8
coming out shortly. It is being very actively developed and there are often
many breaking changes between versions as they tune the API before version
1.0.
BR
Eske
2009/9/23 Peter Firmstone <[email protected]>
I like the sound of Gradle; http://www.gradle.org/
Seeing as were going to support the use of Groovy, for configuration, this
seems very interesting:
From the Gradle Website:
Gradle is a build system which provides:
* A very flexible general purpose build tool like Ant.
* Switchable, build-by-convention frameworks a la Maven (for Java
and Groovy projects). But we never lock you in!
* Powerful support for multi-project builds.
* Powerful dependency management (based on Apache Ivy).
* Full support for your existing Maven or Ivy repository infrastructure.
* Support for transitive dependency management without the need for
remote repositories and pom.xml or ivy.xml files (optional).
* Ant tasks as first class citizens.
* /Groovy/ build scripts.
And from the User guide:
2.2. Why Groovy?
We think the advantages of an internal DSL (based on a dynamic language)
over XML are tremendous in
case of build scripts. There are a couple of dynamic languages out there.
Why Groovy? The answer lies in
the context Gradle is operating in. Although Gradle is a general purpose
build tool at its core, its main focus
are Java projects. [2] In such projects obviously the team members know
Java. One problem we see with Ant
[3] and Maven is, that it involves a lot of knowledge only available to the
build master. Such builds are very
hard to comprehend, let alone to modify by a person not deeply involved
with those tools. <insert>This speaks to me!</insert>
We think a build should be as transparent as possible to all team members.
You might argue why not using Java then as the language for build scripts.
We think this is a valid question.
It would have the highest transparency for your team and the lowest
learning curve. But due to limitations of
Java such a build language would not be as nice, expressive and powerful as
it could be. [4] Languages like
Python, Groovy or Ruby do a much better job here. We have chosen Groovy as
it offers by far the highest
transparency for Java people. Its base syntax is the same as Java's as well
as its type system, its package
structure other things. Groovy builds a lot on top of that. But on a common
ground with Java.
License: Apache v2.
Anyone on the list played with Gradle?
Cheers,
Peter.
