With nearly two decades of experience working in the IT industry in various roles as Enterprise technology consultant, Java Architect, project leader, Engineer, Designer and Developer, Mr. Knutson has gained a wide variety of experience in disciplines including JavaEE, Web Services, Mobile Computing and Enterprise Integration Solutions. Over the course of his career, Mr. Knutson has enjoyed long lasting partnerships with many of the most recognizable names in the Health Care, Financial, Banking, Insurance, Manufacturing, Telecommunications, Utilities, Product Distribution, Industrial and Electronics industries employing industry standard full software life cycle methodologies including the Rational Unified Process (RUP), Agile, SCRUM, and Extreme Programming (XP). Mr. Knutson has also undertaken speaking engagements, training seminars, white paper and book publishing engagements world-wide. As an active Blogger and tweeter, Mr. Knutson has also been inducted in the prestigious DZone.com Most Valuable Blogger (MVB) group and can be followed at http://www.dzone.com/page/mvbs and twitter at http://twitter.com/mickknutson. Able to quickly and effectively adapt to any phase of an existing project from Business Modeling to Production Support, Mr. Knutson’s wide array of technical expertise in OOA / OOD / OOP, Java, J2EE, Internet, Oracle, Enterprise Integration and Message Oriented Middleware allow him to seamlessly integrate into your Information Systems project at any phase and provide immediate productivity. Mr. Knutson is exceptional at team building and motivating either at a peer-to-peer level, or in a leadership role with excellent communications skills and the ability to adapt to all environments and cultures with ease. Mick is a DZone MVB and is not an employee of DZone and has posted 18 posts at DZone. You can read more from them at their website. View Full User Profile

Variable Scoping With a Multi-Module Project

03.10.2012
| 5687 views |
  • submit to reddit

I have been very frustrated by Gradle and variable scoping in a multi-module project. I have wasted countless hours trying to follow examples that simply do not work as stated, and having limited examples for the type of multi-module project that I wanted to create.

So first I started with a List variable at the outermost part of my build.gradle called versions:

def versions = [root: "1.0.0"]

buildscript {

    List list1 = ["com.baselogic:common:${versions.root}"]
    List list2 = ["com.baselogic:extended:${versions.root}"]    

    println "--- buildscript ---"
    println "versions: $versions"
    println "list1: $list1"
    println "list2: $list2"
}

allprojects {
    println "--- allprojects ---"
    println "versions: $versions"
    println "list1: $list1"
    println "list2: $list2"
}

subprojects {
    println "--- subprojects ---"
    println "versions: $versions"
    println "list1: $list1"
    println "list2: $list2"
}

project('ch01') {}

The issue is that ‘def versions’ was not accessible in buildscript, allprojects, or subprojects scope.
Then I moved this variable to the ‘buildscript’ section:

buildscript {
    def versions = [root: "1.0.0"]

    List list1 = ["com.baselogic:common:${versions.root}"]
    List list2 = ["com.baselogic:extended:${versions.root}"]    

    println "--- buildscript ---"
    println "versions: $versions"
    println "list1: $list1"
    println "list2: $list2"
}

allprojects {
    println "--- allprojects ---"
    println "versions: $versions"
    println "list1: $list1"
    println "list2: $list2"
}

subprojects {
    println "--- subprojects ---"
    println "versions: $versions"
    println "list1: $list1"
    println "list2: $list2"
}

project('ch01') {}

Now buildscript has access to that variable, but allprojects and subprojects both cannot access this variable.

So by removing ‘def’ from versions like to have: versions = [root: "1.0.0"] versions was found by all scopes but now the next variable issue.
‘List list1′ and ‘List list2′ were both accessible to the buildscript but not to allprojects or subprojects.

UGGG!!!!!

So by removing the ‘List’ identifyer, finally all scopes had access to the variables I have set. Here is what I finally ended up with:

buildscript {
    versions = [root: "1.0.0"]

    list1 = ["com.baselogic:common:${versions.root}"]
    list2 = ["com.baselogic:extended:${versions.root}"]    

    println "--- buildscript ---"
    println "versions: $versions"
    println "list1: $list1"
    println "list2: $list2"
}

allprojects {
    println "--- allprojects ---"
    println "versions: $versions"
    println "list1: $list1"
    println "list2: $list2"
}

subprojects {
    println "--- subprojects ---"
    println "versions: $versions"
    println "list1: $list1"
    println "list2: $list2"
}

project('ch01') {}

 

Which gave me this output:

C:\>gradle -t -a
--- buildscript ---
versions: [root:1.0.0]
list1: [com.baselogic:common:1.0.0]
list2: [com.baselogic:extended:1.0.0]
--- allprojects ---
versions: [root:1.0.0]
list1: [com.baselogic:common:1.0.0]
list2: [com.baselogic:extended:1.0.0]
--- allprojects ---
versions: [root:1.0.0]
list1: [com.baselogic:common:1.0.0]
list2: [com.baselogic:extended:1.0.0]
--- subprojects ---
versions: [root:1.0.0]
list1: [com.baselogic:common:1.0.0]
list2: [com.baselogic:extended:1.0.0]
:tasks

------------------------------------------------------------
All tasks runnable from root project
------------------------------------------------------------

 

I hope this can save someone else some frustration with variable scoping in a multi-module project.

 

Published at DZone with permission of Mick Knutson, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Ted Naleid replied on Sat, 2012/03/10 - 2:11pm

This is not really a bug or fault of gradle, it's just the way variable scoping works in groovy scripts.  This stackoverflow answer goes into how script binding works and why you can't see things inside closures that are declared outside of closures. If you don't declare something with def or a class name, it just becomes part of the script's binding and is accessible just about anywhere as a global variable.

Roger Studner replied on Thu, 2012/12/06 - 6:59pm

One can also look at the Groovy 1.8+ AST Transformation @Field, which puts variables (of a named type) into the Binding thus achieving the affect above.

Bruce Edge replied on Mon, 2013/09/23 - 5:16pm

Thanks, saved me time.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.