Frank Wilson wrote:
>
> The problem I am having with Gradle is that it seems mostly focused on
> hierarchical project layouts
>
Not at all. A Gradle multi-project build has a logical and a physical
layout, which are independent of each other. As Rene has already shown, the
physical layout is freely configurable. For flat physical layouts, Gradle
provides a convenience method "includeFlat", which is a good fit for Eclipse
projects.
Frank Wilson wrote:
>
> What is the best way to get gradle code in BuildCommon to configure gradle
> code in ModuleA and B?
>
In the BuildCommon build script just say:
project(":ModuleA") {
...
}
project(":ModuleB") {
...
}
Frank Wilson wrote:
>
> It seems that "subprojects" in Gradle only refers to subdirectories
>
No, it refers to logical subprojects.
Frank Wilson wrote:
>
> I would also add that (to me at least) it would be elegant if developers
> didn't have to checkout BuildCommon if they didn't intend to modify it.
>
If the BuildCommon build script is essential for building ModuleA and
ModuleB, it has to be present in the working directory. I'm not sure what
the purpose of BuildCommon is, and if it should really serve as the root
project. An alternative would be to add another project that just serves as
the root project and doesn't contain any code.
Frank Wilson wrote:
>
> However if I execute Gradle from one of the subprojects it has no
> knowledge of the tasks that are normally configured by the build.gradle
> script in BuildCommon. Is there a best practice for doing this backwards
> reference to BuildCommon?
>
The user guide has detailed information on this. For projects with flat
physical layout, the directory of the root project must be named "master".
Otherwise, running the build from a subproject directory won't work (but you
can still run a subproject build from the root project directory with
"gradle :subproject:build"). I'm not very fond of the "master" naming
convention; maybe we could make this configurable.
Frank Wilson wrote:
>
> I was thinking that these back references would be helpful for building
> certain subsets of the workspace projects. For example running the
> (re)build task from within ModuleA would only build the projects that
> ModuleA depends apon.
>
Subprojects and depended-upon projects are two different things. To build
the former say "gradle build" in the parent project. To build the latter say
"gradle buildNeeded" in the dependent project. There is also "gradle
buildDependent" to build a project's dependent projects.
Frank Wilson wrote:
>
> /*
> * I intend to generate the following includes automatically
> * depending on what projects have been checked out
> */
> include 'ModuleA'
> include 'ModuleB'
>
No need for code generation here (if that's what you mean). Instead, you
could do something like this (I haven't tested this code):
includeIfCheckedOut 'ModuleA'
includeIfCheckedOut 'ModuleB'
// list all other modules here
def includeIfCheckedOut(projectName) {
if (rootProject.file("../$projectName").exists()) include(projectName)
}
If you need to support the case where checked-out projects depend on
not-checked-out projects which are, however, available from a repository,
you will have to do some scripting in build.gradle similar to the above. An
alternative would be to check out everything and rely on Gradle's
incremental build capabilities.
Cheers,
Peter
--
View this message in context:
http://gradle.1045684.n5.nabble.com/multi-module-Gradle-builds-in-eclipse-tp3347599p3348371.html
Sent from the gradle-user mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
