Op 1-4-2014 1:07 schreef Adam Murdoch:
On 31 Mar 2014, at 11:44 pm, Jeroen van der Vegt
<jeroen.van.der.v...@technolution.eu
<mailto:jeroen.van.der.v...@technolution.eu>> wrote:
Hello,
We're using Gradle to build programs we develop using Eclipse. All of
our programs are stored in the a multi-project tree. Because we're
using Eclipse, the folder structure within a program looks like this:
<programX>/workspace/subproject1
<programX>/workspace/subproject2
<programX>/workspace/subproject3
<programX>/workspace/gradle
<programX>/workspace/gradle/wrapper
The folder 'workspace' is our Eclipse workspace folder. Due to
Eclipse limitations, this folder cannot contain files from our code
repository.
The 'gradle' folder contains the global Gradle files
'settings.gradle', 'gradle.properties', the global 'build.gradle' and
the 'gradlew' scripts. The 'settings.gradle' file contains all
subprojects using the 'includeFlat' directive.
Every 'subproject?' folder contains a project specific 'build.gradle'
file.
The problem with this setup comes when working from the command line:
we can only execute 'gradlew' commands from the 'gradle' folder, not
from any subproject folder. For it to work from other folders, we
should rename the folder 'gradle' to 'master' as explained here:
http://www.gradle.org/docs/current/userguide/build_lifecycle.html#sec:initialization
The folder name 'master' is not very clear in our programs, as we're
often building client/server or master/slave -like programs. We'd
like to see an option to override the name of the folder Gradle is
looking for. As far as we can see, using a system property for this
is the only way to do this as no configuration file is available at
that point in Gradle execution.
We’re pretty unlikely to support using a system property for this.
Instead, we'd want some way that the structure of the build is defined
by the contents of the files in source control, plus some conventions,
and not by something in the environment.
So, we have a few options:
1. Look for the settings script relative to where the wrapper
configuration is, e.g. in `gradle/settings.gradle`.
2. Add `gradle’ as an alternative to `master`. We’d look for a
settings script at `master/settings.gradle`, and if not found we’d
look in `gradle/settings.gradle`.
3. Declare the location of the settings script in each build script.
4. Declare the location of the settings script in the wrapper properties.
#1 and #2 are more or less the same option. I’d go with one of these.
I've implemented #2 in this commit:
https://github.com/jvdvTechno/gradle/commit/f764cf15c38aabd63dd0f6afca36006d465ca07a
. Should I create a pull request for this?
Jeroen.
