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
