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.
I don't have a good alternative to propose, other than to suggest the
solution really should end up in the build script first, and
command-line second (if at all).
My gut feel is that this problem is related to the development process
or workflow. Generally, these tailored artifacts are built because they
are needed to fulfil some development process step. Perhaps if we
introduce the concept of the development process into the model,
defining the artifacts becomes a bit clearer.
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?
I think so, regardless of what we come up with for
environment/profiles/whatever-they-are
6.) Make it easy to apply any init/property files from a build.gradle.
+1
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
