On Aug 19, 2009, at 9:27 AM, Trond Andersen wrote:
<snip>
Is this an example on how to approach this:
http://docs.codehaus.org/display/GRADLE/Environment+management
I wasn't really aware of this page. Nor did I know about the Groovy
ConfigSlurper class. Thanks for pointing this put and apologies to
Erwan for not having paid attention to this.
This confluence page was made for 0.5.x, but I guess the main
concept is similar for Gradle 0.7.
With the following scenario:
I have a gradle.properties which defines some properties:
service.url=http://localhost:8080/MyApp/MyService?wsdl
some.property=some value
another.property=another value
Then I have gradle.properties.systest which defines the following
properties
service.url=http://systest/MyApp/MyService?wsdl
another.property=systest value
In the gradle.properties.prod the following property are defined:
service.url=http://prod/MyApp/MyService?wsdl
Are there any tools in Gradle/Groovy that can be used to accomplish
so that the properties which isn't overridden becomes the default
value defined in the gradle.properties, but whenever I override them
when building for a specific environment, the overridden properties
get use?
The ConfigSlurper class seems to offer this. See: http://docs.codehaus.org/display/GROOVY/ConfigSlurper
(under Special "environments" Configuration)
The question remains how Gradle should better support this in the
future out-of-the-box.
Generally there are two ways of configuring. One is via a script the
other is via a properties file. I think we need both, as scripts are
much more powerful but properties file are easier to modify by code
(e.g. incrementing a version property).
This is the current situation with Gradle (trunk):
user specific configuration:
~/.gradle/gradle.properties
~/init.gradle (or any custom location you may specify)
project specific configuration
build.gradle
<PROJECT_HOME>/gradle.properties
The concept of environments is relevant for project specific
configuration as well as for user specific configuration. At the
moment you have to do the following.
For project and user specific environment handling:
1.) start Gradle with: gradle -PtargetEnvironment=DEV
2.) Either use the ConfigSlurper to parse and additional config script
or do it directly in you build script:
build.gradle: if (targetEnvironment == DEV) { service.url=http://localhost:8080/MyApp/MyService?wsdl
}
It is a bit awkward to use environment specific property files as we
don't offer a way yet to apply them directly to projects.
Here is a proposal on how Gradle can better support profiles and
general configuration in the future:
We introduce a new command line option E:
1.) gradle -E dev,full clean compile
2.) init.gradle and build.gradle:
profiles {
dev {
url = 'x'
}
prod { ... }
full { .. }
}
3.) All property files in user home and project home which end with
one of the -E parameters are applied (in the order of declaration).
4.) A project can define a default profile.
5.) As it is possible to specify a custom location for init files,
this should also be possible for gradle.properties files. Should it be
possible to specify more than one init/property file? Should we use
the same command line options to specify init/property files?
6.) Make it easy to apply any init/property files from a build.gradle.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
