Properties - pford68/gradle-examples GitHub Wiki

Contents

• Project Properties
• Gradle Properties

Project Properties vs. Variables

Variables are declared with the def keyword. They are only visible in the scope in which they are declared.

On the other hand, any property in a project build script is also visible to all the sub-projects. You can use properties to define common configurations, and to extract build logic into methods which can be reused by the sub-projects.

Properties are declared within the ext namespace:

ext {
    springVersion = "3.1.0.RELEASE"
    emailNotification = "[email protected]"
}

The properties can then be referenced by $: e.g., $version.

All enhanced objects in Gradle's domain model can hold extra user-defined properties. This includes, but is not limited to, projects, tasks, and source sets. Extra properties can be added, read and set via the owning object's ext property. Alternatively, an ext block can be used to add multiple properties at once. Again, once the properties have been added, they can be read and set like predefined properties.

Extra properties can be accessed from anywhere their owning object can be accessed, giving them a wider scope than local variables. Extra properties on a project are visible from its subprojects.

Dynamic Properties Not Allowed

As of Gradle 2.10, dynamic (undeclared) properties are deprecated because they are considered unsafe. They were replaced with the ext namespace. By requiring special syntax for adding a property, Gradle can fail fast when an attempt is made to set a (predefined or extra) property but the property is misspelled or does not exist. All of this is explained here:

Gradle domain objects are extensible in a number of ways. The most lightweight being that new properties can be added on demand. While this feature has proven to be very convenient for storing global settings and for inline custom tasks (among other things), it has also proven to be just a little too risky. With this mechanism, it is easy to create a new property on an object simply by misspelling the name of an existing property.

As an example, it can be all too easy to do this:

compileJava { classPath = configurations.compile }

> In this case we are trying to manually set the compile classpath when we compile our Java source. However, what we are really doing is creating a new property called 'classPath' and assigning the 'compile' configuration to it. This is going to have no effect whatsoever as the property that is used to specify the compile classpath is called “'classpath'”. This can be a tricky and time consuming problem to track down.


## Gradle Properties
These are set in a gradle.properties file.  Gradle looks for gradle properties files in the following locations.
The properties are applied in this order (if an option is configured in multiple locations the last one wins):

* from gradle.properties in project build dir.
* from gradle.properties in gradle user home.
* from system properties, e.g. when `-Dsome.property` is set on the command line.

### Configuration
See [Configuration](configuration) for Gradle Configuration properties.


## References
* https://docs.gradle.org/current/userguide/writing_build_scripts.html
* https://docs.gradle.org/current/userguide/organizing_build_logic.html

> Any method or property defined in a project build script is also visible to all the sub-projects. You can use this to define common configurations, and to extract build logic into methods which can be reused by the sub-projects.

* https://discuss.gradle.org/t/deprecation-of-dynamic-properties-and-the-new-extra-properties/7745
* [Gradle Configuration Properties](https://docs.gradle.org/current/userguide/build_environment.html#sec:gradle_configuration_properties)

## Related
* [Configuration](configuration)