zebra
zebra

Reputation: 1338

how to dump all gradle values used for build

we have a multi-project gradle build in android studio. every now and then we have to change something in it, and usually its only 1 or two lines of code, but its never easy knowing where to put those. I find it quite hard to know which properties exist where so I would love to have something like dump-everything where I could see all properties and their children at the point in time, this would make changes much easier

I have found this

def void explainMe(it){
    //println "Examining $it.name:"
    println "Meta:"
    println it.metaClass.metaMethods*.name.sort().unique()
    println "Methods:"
    println it.metaClass.methods*.name.sort().unique()
    println "Depends On:"
    //println it.dependsOn.collect({it*.getName()})
    println "Properties:"
    println it.properties.entrySet()*.toString()
        .sort().toString().replaceAll(", ","\n")
}

which is OK, but I would like to call it on top level scope and for all its children recursively, and in best case store output to file to be able to search through it. any idea would be appreciated? alternatively would it be possible to attach debugger to gradle build and inspect /watch variables inside?

thanks

Upvotes: 19

Views: 25608

Answers (1)

Peter Niederwieser
Peter Niederwieser

Reputation: 123920

Gradle has very specific support for inspecting certain parts of the build model (gradle tasks, gradle help --task taskName, gradle properties, gradle projects, gradle dependencies, gradle dependencyInsight, etc.), but doesn't currently have a generic feature for deep inspection of arbitrary build model properties and their values. Instead one would typically add some printlns to the build script and/or consult the Gradle Build Language Reference.

To answer your second question, a Gradle build can be debugged in the same way as any other external application. The necessary JVM args (typically provided by the debugger) can be set via the JAVA_OPTS or GRADLE_OPTS environment variable. It's probably best to execute Gradle with --no-daemon when debugging.

Upvotes: 17

Related Questions