On 14/03/2012, at 11:34 AM, Russel Winder wrote:
> Groovy scope rules mean that outside of a class definition, i.e. in a
> script:
>
> final x = 1
> def X ( ) {
> x
> }
>
> fails due to the way code is constructed into a class. The usual trick
> is to make use of the script binding:
>
> x = 1
> def X ( ) {
> x
> }
>
> works fine -- in a Groovy script. This used to work fine in a Gradle
> script as well, but this is no longer the case. Deprecation warnings
> about project.ext get issued.
If you change `x = 1` to `ext.x = 1` everything will work fine.
The core issue is that the binding in a Gradle script is not really the a
binding for practical purposes. The binding delegates to a Gradle domain
object, usually Project. This is by design.
> One solution is to never use functions in Gradle scripts, but always to
> use variables bound to lambda functions.
>
> Is there though a way around this fact that Gradle scripts obey Groovy
> script scoping but no longer have a script binding usable in the Gradle
> script?
You can just use “ext.«var» = «val»” as per above everywhere.
This change came about because too many people were coming unstuck in
misspelling the name of properties they were trying to set, and instead
creating new properties which would just silently not behave the way they were
expecting. Very painful to debug.
The “ext” space makes it explicit that you are creating something “extra”.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
