Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of eske@allsorts.dk designates
 209.85.218.226 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4AB9ED4B.4020501@zeus.net.au>
References: <4AB9ED4B.4020501@zeus.net.au>
Date: Wed, 23 Sep 2009 11:56:17 +0200
Message-ID: <3388b1690909230256h3187c633hc4337afa8bde7e28@mail.gmail.com>
Subject: Re: Groovy Build Scripts - Anyone used Gradle?
From: Eske Sort <eske@allsorts.dk>
To: river-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0003255585b2ea992904743bb9f1

--0003255585b2ea992904743bb9f1
Content-Type: text/plain; charset=ISO-8859-1

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 <jini@zeus.net.au>

> 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.
>
>
>

--0003255585b2ea992904743bb9f1--