22 May 17:38
Best Practices for storing common configuration values
I am curious about what others are doing in their projects to store common configuration values. Please give feedback on your approaches and I welcome opinions on the approaches I am sharing here.
I use the dynamic properties capability heavily to share common configuration values and, I take advantage of the gradle.properties file do achieve this. With the recent switch to "moving away" from dynamic properties is this solution future proof?
Here are examples of how I do it and questions related to it.
1. Holding version numbers in gradle.properties like:
SPRING_VERSION=3.0
HIBERNATE=3.4
So you would see in the build.gradle something like this:
dependencies {
compile {
[group: 'org.springframework', name: 'spring-context', version: "$SPRING_VERSION"],
[group: 'org.springframework', name: 'spring-jdbc', version: "$SPRING_VERSION"],
[group: 'org.hibernate', name: 'hibernate', version: "$HIBERNATE_VERSION"],
[group: 'org.hibernate', name: 'ibernate-entitymanager', version: "$HIBERNATE_VERSION"]
}
}
This has a lot of value. You get one place to change versions especially for framework apis that have multiple jars of the same version. It also is great for multiple project setup ups. What do others do here if anything? I was also considering moving the list of dependencies to a common area away from the build.gradle file. This would reduce the noise in those files and get a more comprehensive sharing capability. I am considering something like below in either a gradle.properties or some sort of initializing gradle script.
SPRING_API = [[group: 'org.springframework', name: 'spring-context', version: "$SPRING_VERSION"],
[group: 'org.springframework', name: 'spring-jdbc', version: "$SPRING_VERSION"]]
Then it would be possible to do:
dependencies {
}
2. Have values like database connections and target environment values (dev, test, production) in the either gradle.properties or an environment specific properties file.
I load this into the build script as dynamic properties and load them based on a target environment.
databaseUserName=user
databasePassword=pass
databaseName=dbName
With this approach you can apply these to the build script and then share them across tasks or even nicer inject a list these of properties into a Groovy template engine. We generate persistence.xml, application properties files, and target container config files this way.
I know that the ExtraPropertiesExtension looks like the new direction I am just not clear on that being the case, is that their intended use? if so will we see a change in future versions where properties from gradle.properties will be populated into the project.extensions instead of as dynamic properties on the project object itself?
Thanks,
Jas
RSS Feed