Support arbitrary directory for environment files.

[taorg]

Currently only files located in the same directory where Gradle build is located are loaded. This is ok, but when you want to have separate source code an configurations, it would be nice to have an extra property to allow where gradle-properties-plugin look for property files.

[stevesaliman]

Can you give me more details on the use case you have in mind?

My original thinking was that the root of every project would have the configuration files for that project. The idea was that a new developer would be able to find everything needed to build a project right there in the project's root, without having to hunt for all the touch points.

Steve

[taorg]

Hello Steven, yes you are right, I'm not saying your approach is not appropriate for developing purposes, and indeed is great for developing and testing. But when you have a peace of software, that needs to be installed (and build) in many different clients, with passwords, seeds, or confidential data, you keep this files in a different location than the regular source. Is in this situations when it would be interesting to be able to launch the build adding a parameter indicating where the client-environment properties are. Antonio

[stevesaliman]

Yes, you definately don't want to be checking in credentials to the repository. I was also thinking about things like Tomcat's home directory, which would be the same from project to project on a given box.

A lot of tools allow you to put a file in your home directory, and use that for all projects. Perhaps the plugin could read $HOME/gradle.properties or $HOME/.gradle/gradle-properties, if it exists. Are you thinking of a single common properties file, or one for each environment (dev, qa, etc.)?

There would have to be a clearly defined order of precedence for a property that is defined in multiple places. Something like this: Command line, project properties, $HOME properties. The first place to define a property wins. I could also do something like $HOME/gradle-.properties if we needed things like QA credentials, Prod credentials, etc.

What do you think?

[taorg]

Yes having several default directories is a good idea in any case, but, I was thinking about a more dynamic way, using -P gradle mechanism to indicate the gradle-.properties directory. I'm focusing in building in a single machine (real situation) 30 EARs for different clients, with almost the same software, except some properties and few specific jars. I would like to invoke something like: gradle -PpropertiesLocalDir=Client1LocalDir -PenvironmentName=PRE gradle -PpropertiesLocalDir=Client1LocalDir -PenvironmentName=PRO gradle -PpropertiesLocalDir=Client2LocalDir -PenvironmentName=DEV

[stevesaliman]

I've been thinking about how I could go about implementing this and staying in the spirit of how Gradle loads properties. I've come up with an idea on how to do this, and I'd be curious to hear your opinion on it.

Gradle evaluates properties in a particular order. The last item to define a property wins. Gradle's order:

1) the project's gradle.properties file 2) ~/.gradle/gradle.properties 3) The value passed on the command line with -P

Applying the property plugin would cause gradle to effectively use this order:

1) The project's gradle.properties file 2) The project's gradle-${environmentName}.properties file (default is "local") 3) ~/.gradle/gradle.properties 4) ~/.gradle/gradle-${userName}.properties (userName is optional. If not specified, it just skips this one. 5) the command line value with -P

In this manner, you could just set up clients as different "users" in your home gradle directory.

What do you think?

[taorg]

I think it's great solution, it perfectly suits the needs exposed in this issue, and it is a non intrusive approach for Gradle. No further questions your honor.

[stevesaliman]

Version 1.1 of the properties plugin has been release, and it addresses the issue as we've been discussing. Thank you for the idea. I think the new version fits in much better with the way Gradle wants to do things natively.

Let me know how it works in your situation.