I have this in my settings.gradle:
include ‘:api’, ‘:core:jdbc’, ‘:core:neo4j’, ‘:web:wicket’
so I expect only these four projects to be build. When I invoke gradle, though, ‘core’ and ‘web’ are build as well and (empty) jars are produced. Am I configuring things wrong? Why do I need to specify the included projects in settings.gradle when gradle scans and build every directory in the structure anyways?
wujek
Gradle doesn’t scan directories for projects, at least not out of the box. 'include ‘web:wicket’ means “include a project named web, and a subproject thereof named wicket”. If you only want a “wicket” project (although you also have a “web” directory), use ‘include ‘web/wicket’’.
Is there any documentation which describes the differences in detail? For example, what is the difference between ‘web/wicket’ and ‘web/:wicket’ or ‘:web/wicket’? Are all of them allowed? Thanks for your help.
I would expect that it’s documented in the user guide and/or DSL reference.
Names can be separated with ‘:’ or ‘/’. ‘/:’ might work but doesn’t make a lot of sense. Leading ‘:’ is optional (for ‘include’). I’ve already tried to explain the difference between ‘:’ and ‘/’.
I think it’s not in the user guide, and that’s what I found for include in the DSL reference:
"Adds the given projects to the build. Each path in the supplied list is treated as the path of a project to add to the build. Note that these path are not file paths, but instead specify the location of the new project in the project heirarchy. As such, the supplied paths must use the ‘:’ character as separator.
The last element of the supplied path is used as the project name. The supplied path is converted to a project directory relative to the root project directory.
As an example, the path a:b adds a project with path 
b, name b and project directory $rootDir/a/b."
This actually says the projects must be separated with ‘:’; nowhere does it mention ‘/’ is allowed. I also couldn’t find any mention of the fact that ‘:web:wicket’ also treats :web as a buildable project. If anything, the example above: “path a:b adds a project with path b, name b and project directory $rootDir/a/b.” It doesn’t say anything about addind ‘a’.
Would you like me to issue a jira for this?
Include paths determine the defaults for project names, project paths, and project directories. That makes the details tricky.
The first paragraph you cite is not very clear. AFAIK, at least the first part of an include path is treated as a file path.
You can’t have a project with project path ‘b’ without also having a project with path ‘:a’. Of course, the docs could be more explicit about this.
I think the best way to improve the docs is to add a few more examples. The best way to help with that is to submit a pull request.
Hey,
Take a look in the user guide http://gradle.org/docs/current/userguide/userguide_single.html#sec:multi_project_builds, then to ‘Hierarchical layouts’ section it describes what happens when you use ‘:’ in the settings.gradle
Later on it is described how to configure an unconventional dir for a project. For example, you can have project ‘neo4j’ and configure it’s directory to ‘core/neo4j’
I would strongly discourage using ‘/’ in the project names (e.g. doing "include ‘foo/bar’ "). It is really confusing because the project name will get confused with filesystem path.
The problem of empty jars is probably because you apply a java project for all projects, including the ‘core’ and ‘web’ which apparently is not what you want. To solve that, you can tweak your configuration injection so that java plugin is applied only to projects you want.
Hope that helps!
As Peter mentioned - if you find some documentation unclear please submit a pull request 
Hi. Thanks for the pointers, I missed out on these parts of the documentation previously.
The idea with the slashes is the following: we have an api module, and core module. Currently, it is being implemented with neo4j, but we might implement it in oriondb at some point (neo4j has some licensing problems) or even a relational db (right…). Then, the ‘core’ would be just an umbrella, and beneath it would be other projects that are implementations using various technologies, so: core/neo4j, core/oriondb, core/jdbc … If it is all top-level I think we can loose control at some point, and it is not that well structured. Also, api - core is just one of the examples that we have. Another one is the frontend - now its wicket, but there is some talks that clients want some rich desktop app with javafx2 and so on - this could all also be scoped. At least that’s my idea.
Yes, I was applying ‘groovy’ to all subprojects, and when I do filtering, it all works fine, thanks.
As for the pull request - I now this is an open source project and I should not complain and all, and if i don’t like something I should try to fix it myself. However, as you (mockito, gradle, whaterver else) most likely know time is limited, especially when one tries to create a small startup. There are a lot of projects that we use and we simply just can’t do pull request for all of them, this is just too much - gradle, groovy, neo4j, wicket, a lot of others - everybody would like pull requests, but this is just not doable. Filing issues is still more than most people do, I think, at least in my environment - they just ignore things once they know how it works, which doesn’t help further generations ;d in any way. And we are talking just of my free time development, there is also my day job 40hrs / week which also uses many (other) projects. I am sure you understand. I might be mistaken, but Peter Niederweiser works gor gradleware and does spock in his free time, maybe some others - but he also has limits, as everybody - I’m sure you aren’t all comitters to all open source projects you use. wujek
I just wanted to say that I had the same issue as wujek. I used Szczepan’s answer as follows: https://gist.github.com/allengeorge/7339905
I hope that’s the right approach! It seems to do the right thing, so I’ll keep using it until told otherwise