Thank you for answering. I will check these project templates.
It might be worth having a 'sample' java project.
Despite that I said, the wizards are mostly for educational purposes. I do want them to be useable in practice. That is, it is unlikely that I can guess the libraries a user will use (it would feel like Visual Studio adding a "Class1.cs" to new projects, who knows you might just need one? :)). Except perhaps for JUnit but I already added that one. That said, it truly wouldn't hurt to at least add commented dependencies.
I would not add the empty settings.gradle. If they are empty, they are not really needed.
I add an empty settings.gradle, so Gradle stops looking for settings.gradle file in a parent directory. To avoid possible issues, if the user had a settings.gradle in a parent directory by accident.
I'm not sure I like the 'parent.gradle' script applied in every child. Why is it needed?
When I first saw Gradle the "subprojects" method in the root script was quite confusing. It was obvious that subprojects had a build.gradle (I didn't know at that time, that they can be renamed). So, when I tried to understand the script of a project, I just didn't know where to look for, it is not at all obvious, while "apply from" is. Also, almost every build script I have seen depends on the fact that the build.gradle of the root project is executed before its child project. This isn't necessarily what I expect, I expected the subproject's script to execute first when I execute gradle from that dir. Other than these, aren't future plans to disallow one project to configure other projects?
It would be cool if the multi project build was somewhat realistic.
Currently when you create a new root project no subproject is added, you have to add as many subprojects as you one separately in another project wizard window. Though obviously, it would be reasonable to add at least a single subproject.
Sooner or later we'll have a top level support for generation of project templates. We can also provide this functionality via the tooling api.
That would be nice, making it available through the Tooling API is certainly desirable for me.