On 15/07/2011, at 4:09 PM, Jason Porter wrote:
> This one isn't related to the Signing plugin but I noticed while looking at
> http://gradle.org/releases/latest/docs/dsl/org.gradle.api.tasks.SourceSetOutput.html
>
> The example and the method signature don't match. In the Generated Output
> example it's placing the directory first, then the map, but the method
> signature a little below says map first then dir. Which one is correct?
That's a groovyism.
def m(Map m, File dir) {
...
}
m(new File("file"), foo: "bar", baz: "bat")
When “named“ arguments are encountered like this Groovy effectively turns it
into
m([foo: "bar", baz: "bat"], new File("file"))
Which means the following is also legal:
m(foo: "bar", new File("file"), baz: "bat")
> Signing
> Would it make sense to have the maven plugin also apply the sign plugin (if
> it doesn't already)?
I'm not sure on this, because only a small percentage of people using the
signing plugin will want to sign their artifacts.
> Perhaps at a second pass, it would be nice to have the plugin ask for the
> required properties if they aren't already there, like what the example
> gives. Along those lines before M4 ships that example should be completed as
> I'm sure there will be others that will want to use it.
I'm not sure on this one either, because I really dislike interactive builds
and they shouldn't be encouraged.
As for the example, working on it now.
Thanks for taking the time to have a look.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
