On Aug 26, 2009, at 7:24 AM, Adam Murdoch wrote:
Hans Dockter wrote:
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
This doesn't feel quite right to me:
- I can't use this from the build script. That is, I can't define a
'ciBuild' task which builds the artifacts for the 'staging'
environment. Instead, I have to configure my CI server to pass the -
E staging command-line option to Gradle, and I lose the change
control and documentation goodness that putting the declaration in
the build script gives me.
- I can't build the artifacts for multiple environments in 1 build.
That is, I can't define a release task which builds and publishes
the artifacts for all environments in one build.
These are excellent points and I agree.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
