[BEAM-3253] Swap to use local variable instead of using 'ext'

[lukecwik]

---

Follow this checklist to help us incorporate your contribution quickly and easily:

• Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.

Post-Commit Tests Status (on master branch)

Lang	SDK	Apex	Dataflow	Flink	Gearpump	Samza	Spark
Go		---	---	---	---	---	---
Java
Python		---			---	---	---

[lukecwik]

R: @adude3141
CC: @swegner

[adude3141]

@lukecwik As commented on the other PR, I was convinced, that task implements ExtensionAware, so that that property is scoped to the task. Indeed, the docs seem to support my understanding.

I ll revalidate that... and comment here again.

Sorry for the confusions I might have introduced. Definitelythis var should not have project scope.

[adude3141]

Added that to task config:
println "task: ${outFile}"
println "task: ${ext.outFile}"
println "project: ${project.outFile}"
println "project ext: ${project.ext.outFile}"

project outfile throws exception as expected

Could not get unknown property 'outFile' for project ':beam-examples-java' of type org.gradle.api.Project.

Of course u might access it like

${project.validateShadedJarDoesntLeakNonOrgApacheBeamClasses.outFile}

but that's what was intended...

Or do you think even a task property has to broad of a scope?

[lukecwik]

I was incorrect in thinking this would have made a project property and thanks for showing me that it is a task property. In this case it doesn't matter but I don't see much value in having the 'outFile' property be consumed by any chance versus using Gradles definition of outputs already.

I'll close this for now, if you also think that exposing outFile isn't useful, feel free to re-open.

[adude3141]

Honestly, I just thought outFile to have the proper semantics to justify a task property.

But of course your right, that it currently provides not much value, especially as that property must be treated as readonly.

For instance, one might to try to do a
project.validateShadedJarDoesntLeakNonOrgApacheBeamClasses.outFile=project.file('shoutOutHere')
println project.validateShadedJarDoesntLeakNonOrgApacheBeamClasses.outFile
which unfortunately will not work. I should have implemented an lazy setting as outputs.files { outFile } instead of directly setting outputs.files outFile

But I guess, this does not matter as no one will ever try to overwrite the output file anyway.