I am also hitting this issue using M6:

------------------------------------------------------------
Gradle 1.0-milestone-6
------------------------------------------------------------

Gradle build time: Thursday, November 17, 2011 5:54:12 AM UTC
Groovy: 1.8.4
Ant: Apache Ant(TM) version 1.8.2 compiled on December 20 2010
Ivy: 2.2.0
JVM: 1.6.0_29 (Apple Inc. 20.4-b02-402)
OS: Mac OS X 10.6.8 x86_64

I am executing:

    $ ./gradlew sonar -PsonarHostUrl=http://myurl:12345

At the top level:

    println hasProperty('sonarHostUrl')   // prints true

But in my Sonar block:

sonar {
 println property('sonarHostUrl')    // prints the passed in url 'http://myurl:12345'
 println hasProperty('sonarHostUrl') // prints null
...
}

what happens if you qualify hasProperty with project.hasProperty?

Same issue:

println(project.hasProperty('sonarHostUrl'))  //prints 'true'
sonar {
    println(project.hasProperty('sonarHostUrl')) //prints 'false'
    ...
}

However, this works:

rootProject.hasProperty('sonarHostUrl')

Thanks for the help.

Your problems stem from name collisions:

1. org.gradle.Project.hasProperty() vs. Object.hasProperty() (the latter comes from Groovy)
2. org.gradle.Project.getProject() vs. org.gradle.api.plugins.sonar.model.SonarModel.getProject()

You need to make sure that you really refer to org.gradle.Project.hasProperty(), for example by wrapping the check in a helper method, or by assigning 'project' to a differently named variable and using that instead.

Thanks. Yes, I think I understand. Thus, it might not be an issue per se, but maybe you can explain that in the reference documentation (A note or warning). Being fairly new to Gradle+Groovy, I was assuming that hasProperty "just magically works".

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:

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'.

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.

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.

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

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!

This work for me with Gradle 3.3.