On 31 Mar 2014, at 11:44 pm, Jeroen van der Vegt <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. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com
