Gradle should allow embedding groovy scripts

Since gradle is compiled, this makes it difficult to do many automation tasks that leverage code that is being built.

For example to clean our database, we had to write code like this:

task cleanDB(type: JavaExec, dependsOn: classes) {
    description = "Clean database."
    main = "com.myco.optimize.db.CleanDB"
    systemProperties = runAESysProps + project.properties.dbSystemProps
    classpath = sourceSets.test.runtimeClasspath
}

This meant we had to rework our DBTestUtil class to have a main method. And passing in an arguments would be awkward (string params in main method would be only option, or system params)

In my opinion gradle should allow embedding of groovy scripts that get interpreted at runtime rather than pre-compiled:

task start(type: GroovyScript, dependsOn: classes){
  description = "Clean database."
  classpath = sourceSets.test.runtimeClasspath
  {{
    dbClean = new com.myco.optimize.db.CleanDB
    dbClean.dbType = "optimize"
    dbClean.user = "admin"
    dbClean.pw = "pw"
    dbClean.clean()
  }}
}

the {{ }} tags would indicate the script inside is to be interpreted at runtime.

This would allow easier automation tasks as all existing java code could be leveraged without jumping through many hoops.

There should also be a construct like BuildSrc that allows more sophisticated scripting/classes. The problem with BuildSrc now is it is compiled before execution and any code that references project code that hasn’t been built wouldn’t compile.

Ruby Rake and SBT don’t have this problem as they are interpreted rather than compiled. This makes them very powerful for automation type tasks leveraging project code.

Hi Phil,

Please see my response on http://forums.gradle.org/gradle/topics/running_groovy_closure_in_a_configuration for some code that you can use to do just this. It would be great if someone could pluginize this.

Our longer term strategy here is to improve our model to support allowing a project to depend on the outputs of another project at configuration time. This would be like using project dependencies in the ‘buildscript {}’ block. We are committed to this, but it’s a very complex problem and likely a long road. The work we are doing on parallel execution and configure-on-demand are laying the groundwork for this.

Ruby Rake and SBT don’t have this problem as they are interpreted rather than compiled.

Like Groovy, Scala is a compiled language, and to my knowledge there exists no interpreter for it (just like there is no Groovy interpreter). Would be interesting to know if and how sbt deals with this.