Best approach to load external properties

Old Forum Archive
1

Hello,

During the migration of an ant build i am working out to reproduce the property mechanism we already had in our ant projects.

The general idea is to have different property files for different purposes: - project specific property file: build.properties - environment specific property files: env.properties – Whereas there can be several environment specific property files - Developer specific property files: local.properties (not in the scm) – This is for local modification

The current approach is done with ant and uses the property immutability in ant (first comes first serves).

ant {
    property(file:'local.properties')
    property(file:'env.properties')
    property(file:'build.properties')
}

To be able to migrate our build i have to setup a similar property loading mechanism, but i am not sure which way to go.

Loading the properties can be done in one of the following ways: - Use one of the property loding plugins – http://wiki.gradle.org/display/GRADLE/Plugins#Plugins-JavaPropFilePlugin – http://wiki.gradle.org/display/GRADLE/Plugins#Plugins-PropertiesPlugin – Both offer ways to load properties, but only the JavaProp file is able to load custom files - convert the property files into gradle files and import them - Use the ant snippet from above to load the properties

I am not sure which way to go, currently i favor the one using ant to load the properties (the smallest difference to the ant build).

Some additional question rose during my first attempt: - loading the properties means i have to put them into the ‘ext’ scope, right? - Does gradle support ‘dottet’ properties like ‘part1.part2.part3’, i guess not - Loading the propery files requires the usage of them in the further loading of files. – for example the local properties defines the environment and based on that the ‘right’ environment file is loaded

Any hints on best practices for loading build properties? I do not want to move all the properties in one of the gradle property files i would like to keep them as clean as possible and get rid of the most properties in the current property files if possible.

2

In general, I’d try to avoid having multiple external ‘.properties’ files. Gradle already offers a powerful configuration language, which includes the ability to chop things up into multiple build scripts and selective including them with ‘apply from:’. Therefore, I wouldn’t want to add another layer of configurability that’s restricted to String values and can’t leverage many of Gradle’s features.

If you do want to go forward with this, I’d use one of the plugins if it fits your needs, or write your own mechanism (based on Ant or the ‘java.util.Properties’ class) otherwise.

3

Thanks for your answer, i tend to go with the your suggestion and use ‘apply from:’

There is something i still do not fully understand, i have the following snippet to define extra properties:

ext {
 prop1 = "prop1"
 // this does not work
 // nested.prop2 = "bar"
}
  project.ext.set("nested.prop2","nested")
// This does not work
// project.ext.nested.prop3 = "nested2"
  task printProps << {
 println prop1
 println project.ext.get("nested.prop2")
 project.ext.properties.each {k, v ->
  println "$k: $v"
 }
}

Which results in this output, as expected:

:printProps
prop1
nested
prop1: prop1
nested.prop2: nested

Why is it only possible to assign nested properties with the 'project.ext.set()'method? I have to decide whether i migrate all my properties from a nested notation into a camelCase notation or use the ‘project.ext.set()’ and ‘project.ext.get()’ methods for simply reuse the existing properties.

Migrating forces me to update all the properties everywhere where they are used which might be quite hard to verify afterwards.

4

The property ‘nested.prop1’ isn’t really “nested” in any real sense of the word. It’s really a single property name containing a ‘.’. But in groovy code the ‘.’ causes the ‘nested.prop’ to be interpreted as 2 separate identifiers.

The following mechanisms should work:

ext {
    it."nested.prop2" = "bar"
}
ext."nested.prop3" = "baz"
  println project."nested.prop2"
5

Alternatively, you could create true ‘nested’ properties like:

ext {
    nested = [:]
    nested.prop1 = 'val1'
}
  println project.nested.prop1
6

great, now i understand :slight_smile: I have to improve my groovy skill :slight_smile:

The name nested was not chosen poorly :slight_smile:

7

I moved the property loading mechanism to its own gradle file and i import it in the modules i need the properties. It was quite easy to reproduce the same behavior we already have with the integrated ant :slight_smile:

After investigating the content of the property files i seems that most of them are environment properties and not built time properties :-/