Uploaded image for project: 'Gradle'
  1. Gradle
  2. GRADLE-1826

hasProperty() does not work in allprojects and subprojects closures with command line or explicitly set earlier

    Details

    • Type: Bug
    • Status: Open
    • Resolution: Unresolved
    • Affects Version/s: 1.0-milestone-3
    • Fix Version/s: None

      Description

      When setting a project property hasProperty() always returns false within an allprojects/subprojects block. getProperty() sees it just fine. Where is hasProperty() being delegated to? Explicitly calling it.hasProperty() works, but doesn't seem like it should be necessary.

      if (hasProperty('testProp'))

      { println 'The project sees it' }

      allprojects {
      // NOTE: Where is this going?
      if (hasProperty('testProp'))

      { println 'Allprojects sees it' }

      try

      { println 'Allprojects really sees it, value of: ' + property('testProp') }

      catch (MissingPropertyException mpe)

      { println 'not there' }

      }

        Activity

        Hide
        spina Andrew Spina added a comment - - edited

        I've run into this problem as well and would argue that the behavior is 'surprising' and unintuitive. While it may be expected and understandable to Groovy/Gradle experts, I'd suggest that for someone new to Gradle it may be a significant roadblock.

        The problem seems to come from the fact that 'property' has two different semantics depending on your context. My use case was this:

        build.gradle
        task(run, type: JavaExec) {
        	description = "Runs the map reader. Use -Ptreasuremap=<path/to/instructions> to specify input"
        	main = 'spina.MapReader'
        	classpath = sourceSets.main.runtimeClasspath
                // This doesn't work. Needs to be qualified with project.
        	if(hasProperty("treasuremap")){
        		args = [treasuremap]
        	}
        }
        

        This doesn't work, but section 14.2.1 in This and That (http://gradle.org/docs/current/userguide/tutorial_this_and_that.html) implies that it should work. This seems like a direct contradiction. It may be a large change, but it might be worth using a synonym of property instead of property (perhaps attribute?) to refer to 'injected data'.

        Show
        spina Andrew Spina added a comment - - edited I've run into this problem as well and would argue that the behavior is 'surprising' and unintuitive. While it may be expected and understandable to Groovy/Gradle experts, I'd suggest that for someone new to Gradle it may be a significant roadblock. The problem seems to come from the fact that 'property' has two different semantics depending on your context. My use case was this: build.gradle task(run, type: JavaExec) { description = "Runs the map reader. Use -Ptreasuremap=<path/to/instructions> to specify input" main = 'spina.MapReader' classpath = sourceSets.main.runtimeClasspath // This doesn't work. Needs to be qualified with project. if (hasProperty( "treasuremap" )){ args = [treasuremap] } } This doesn't work, but section 14.2.1 in This and That ( http://gradle.org/docs/current/userguide/tutorial_this_and_that.html ) implies that it should work. This seems like a direct contradiction. It may be a large change, but it might be worth using a synonym of property instead of property (perhaps attribute?) to refer to 'injected data'.
        Hide
        khylo kster added a comment -

        Using gradle 1.3 I encountered this problem.

        Updating the code to project.hasProperty('prop') worked for me.

        I would suggest that the documentation be updated to reflect this.

        Show
        khylo kster added a comment - Using gradle 1.3 I encountered this problem. Updating the code to project.hasProperty('prop') worked for me. I would suggest that the documentation be updated to reflect this.
        Hide
        joerg.schreiner Jörg Schreiner added a comment -

        I encountered this problem with Gradle 1.5. Using hasProperty('prop') did not work. After changing to project.hasProperty('prop') it worked. There is nothing in the manual (14.2.1. Checking for project properties) that warns you of that trap. I naturally expected that hasProperty('prop') and property('prop') could be used in the same way ("if (hasProperty('prop') && property('prop') == 'foo')

        { ... }

        // not working!".

        I suggest you add a warning in the documentation so that the usage of hasProperty() is clarified.

        Show
        joerg.schreiner Jörg Schreiner added a comment - I encountered this problem with Gradle 1.5. Using hasProperty('prop') did not work. After changing to project.hasProperty('prop') it worked. There is nothing in the manual (14.2.1. Checking for project properties) that warns you of that trap. I naturally expected that hasProperty('prop') and property('prop') could be used in the same way ("if (hasProperty('prop') && property('prop') == 'foo') { ... } // not working!". I suggest you add a warning in the documentation so that the usage of hasProperty() is clarified.
        Hide
        mirzmaster Sohail Mirza added a comment -

        Using this.hasProperty('foobar') appears to work as well. I hope this aids others who are encountering the same issue.

        Show
        mirzmaster Sohail Mirza added a comment - Using this.hasProperty('foobar') appears to work as well. I hope this aids others who are encountering the same issue.
        Hide
        bmuschko Benjamin Muschko added a comment -

        As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

        We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

        Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

        • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
        • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

        We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

        Show
        bmuschko Benjamin Muschko added a comment - As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub. We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to. Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by: Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines . Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete. We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

          People

          • Assignee:
            Unassigned
            Reporter:
            merscwog Spencer Allain
          • Votes:
            9 Vote for this issue
            Watchers:
            12 Start watching this issue

            Dates

            • Created:
              Updated:

              Development