Thank for the feedback > > > I've been looking at the user guide, but I haven't been able to see what >> is the best practice when it comes to handling different environments. >> >> Maven has got its build profiles: >> >> >> http://maven.apache.org/guides/mini/guide-building-for-different-environments.html >> >> The use case I've got is that I have a few configuration parameters of the >> application which tells the webapp where to locate some resources by URL. >> These URL's aren't the same for system test, acceptance test and production >> environment and I have a need to parametrize this for different builds. >> > > Profiles are a missing concept in Gradle 0.7. If your configuration is > project specific, you could simple use some system property and set > properties within the build.gradle file according to the value of the system > property. If configuration is user and environment specific (e.g. different > passwords for different environments), you could use a gradle.properties > file with different property name suffixes and then apply them in your build > script. This is hand crafted and pretty straight forward. In 0.8 there will > be the choice of a user specific init script which can modify the build > script.
Is this an example on how to approach this: http://docs.codehaus.org/display/GRADLE/Environment+management 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? At one point we will might support profiles. Possibly environment specific > init scripts. But as said above, you can pretty easily model this concept > yourself already. At least as long as this is about configuration that can > be expressed by properties. Otherwise you would need the init script feature > of 0.8. > > >> Are configuration concept the way to go with Gradle? Any other solutions? >> Using ANT filter tasks? >> > > Do you mean the configurations for assigning dependencies to? > I was thinking about it, but when looking through the documentation I see that configuration does not have anything with my issue. ------- Trond
