I am also a bit disappointed about the documentation here. I know you’ll accept pull requests for improvements, but I cannot write stuff that I cannnot understand from the existing docmentation. Using gradle 1.11 in the following.
What i miss first is a definition of a subproject. So far I gather that anything defined in the settings.gradle counts as a subproject, even if no such folder exists (which I consider a bug, there should be a failure in case of a typo).
It seems that I can organise my subprojects using non-project folders, i.e.
include ‘collection/subproject1’ adds a subproject named ‘collection/subproject1’ with correct subfolder resolution but no subproject ‘collection’, whereas
include ‘collection:subproject1’ implicitly adds two subprojects. I did not see this documented.
The settings command includeFlat is not discussed at all in the multi-module chapter.
It seems that subprojects do not get added recursively, i.e. root - subproject – settings.gradle [include ‘subsubproject’] - settings.gradle [include ‘subproject’]
does not work as might be expected. root in this case does not know about subsubproject.
The command ‘gradle -q projects’ could well be shown and used in the chapter on subprojects at least once.
Regarding coupling, it is still not clear to me whether the real-life example in “56.6.3. Real life examples” has coupled or non-coupled subprojects. I believe the usage of allprojects {} and subprojects {} is only at configuration time (but I a m not even sure about that), and I don’t know whether the usage of “subprojects.each {project…” causes coupling.
Next what I miss is organization of version numbers of dependencies, such as:
depencencies {
compile “org.springframework:spring-core:$SPRING_VERSION”
testCompile “org.springframework:spring-test:$SPRING_VERSION”
compile “org.springframework:spring-context:$SPRING_VERSION”
compile “org.springframework:spring-context-support:$SPRING_VERSION”
compile “org.springframework:spring-beans:$SPRING_VERSION”
compile “org.springframework:spring-aop:$SPRING_VERSION”
compile “org.springframework:spring-aspects:$SPRING_VERSION”
compile “org.springframework:spring-tx:$SPRING_VERSION” } Obviously I want all subprojects using spring to use the same version, and I also want this to work with ‘gradle dependencies’. I also think things look ‘cleaner’ if every subproject has it’s own build.gradle, rather than configuring subprojects in the root projects.
With subprojects, ‘gradle dependencies’ gives me output like: compile - Compile classpath for source set ‘main’. — org.apache.commons:commons-lang3:3.3.0 FAILED
Next, on my trials, I notice that if the root project defines dependencies like: project(‘collection:subproject1’) {
apply plugin: ‘java’
dependencies {
compile(“org.hibernate:hibernate-validator:4.3.1.Final”)
compile(“org.json:json:20140107”)
} }
but the given subproject has an own settings.gradle, the dependencies are not listed when running ‘gradle dependencies’. I cannot decide whether this is a feature or a bug. The role of a settings.gradle in a subproject is mysterious.
Another problem I had was to define a common release number for all decoupled subprojects. I guess that can be done using allprojects {} in the configuration context without coupling the subprojects, But I did not see that in the user guide yet, so +1 for 'Vampire’s request do add this to the docs.
