Setting Gradle arguments for build comparison


(Dan Stine) #1

I’m using the ‘compare-gradle-builds’ plugin with Gradle 1.2. I had some trouble configuring the Gradle build arguments, and I’m wondering if I’m mis-reading the DSL docs?

I ended up using the following configuration block:

compareGradleBuilds {
    sourceBuild {
        gradleVersion '1.2'
        setArguments(['--refresh-dependencies'])
    }
    targetBuild {
        gradleVersion '1.3'
        setArguments(['--refresh-dependencies'])
    }
}

and the arguments were set as expected. But I had expected that this would work, too:

compareGradleBuilds {
    sourceBuild {
        gradleVersion '1.2'
        arguments ['--refresh-dependencies']
    }
    targetBuild {
        gradleVersion '1.3'
        arguments ['--refresh-dependencies']
    }
}

But this simply left the build arguments empty. It didn’t result in a runtime error. It just had no effect.


(Peter Niederwieser) #2

‘arguments […]’ calls ‘getArguments()’ and then indexes into it. ‘arguments = […]’ should work, and probably also ‘arguments([…])’.


(Dan Stine) #3

Okay, thanks.

In general, I can invoke ‘setFoo(bar)’ by writing ‘foo bar’. I do not need to write ‘set’ or use parens or equals.

Is this a special case because the type of ‘bar’ is a List? (In which the square brackets meant to define a List literal instead perform the indexing you describe above.)

Just trying to understand the Groovy magic a little better and refine my mental model.


(Peter Niederwieser) #4

In general, I can invoke ‘setFoo(bar)’ by writing ‘foo bar’.

In plain Groovy, you’d have to write ‘foo = bar’. Gradle enriches tasks and other classes by adding a method ‘def foo(bar) {}’ that allows you to leave off the ‘=’.

As for the ‘[]’, Groovy only allows to leave off parens in some cases. ‘foo[x]’ is never the same as ‘foo([x])’; the former is parsed as “get foo and index into it”, whereas the latter is parsed as “call foo with a list argument”.