I think I found a couple of small issues with the buildSrc project in a Gradle multiproject that can be tracked in JIRA issues.
The first one is that documentation says: 59.3 […] If you need more flexibility, you can provide your own build.gradle. Gradle applies the default build script regardless of whether there is one specified. This means you only need to declare the extra things you need. Below is an example. Notice that this example does not need to declare a dependency on the Gradle API, as this is done by the default build script:
[…]
However, if I put the following build.gradle inside my buildSrc:
sourceSets {
main {
groovy { srcDir myCustomDir }
} }
the build fails because it says it doesn’t know about the Groovy source directory set. I must add:
apply plugin: ‘groovy’
at the beginning in order to make this work. However, this is in contrast with the documentation that says that the default script (which already applies the groovy plugin) is always applied and that I just need to add the extra things I need.
The second small problem I found is this. Normally if you do: gradlew task1 task2 Gradle will execute task1 first and then task2. So, it’s normally equivalent to “gradlew task1” followed by “gradlew task2”. Hence, if I do: gradlew clean build Gradle will execute clean and then build. However, in the special case in which the buildSrc project needs to be built in order to make the whole multiproject build succeed, executing “gradlew clean build” is not equivalent to “gradlew clean” followed by “gradlew build”. Also, “gradlew clean build” totally fails because Gradle actually does the following: 1. build buildSrc 2. clean all subprojects (including buildSrc) 3. build all subprojects (but not buildSrc)
In other words, either “gradlew clean” should not clean buildSrc (and a separate task should be provided for this to occur) or, as a special case, it should run buildSrc:clean before buildSrc:build and only then start to clean & build the actual multiproject.
Gradle always runs “build” for the ‘buildSrc’ build, no matter which tasks you tell it to run for the main build. If you want to run ‘clean’ for ‘buildSrc’ (which shouldn’t be necessary), you’ll first have to ‘cd’ into ‘buildSrc’.
Hmmm… I know that buildSrc is always built no matter which task I run, however sorry, but I don’t understand how this is related to what I described in my original post
I tried to explain how building ‘buildSrc’ works. It doesn’t work like you described in “second small problem”, and I don’t understand what the problem is with how it currently works.
Hi Peter, that was my fault, thank you very much for your support. I discovered that both described behaviours were caused by my script which was erroneously adding ‘buildSrc’ as a subproject of the root project. So both are fixed now.
However, a secondary small glitch occurs now, which is somewhat related to the first issue I described. If I don’t add: ‘apply plugin: ‘groovy’’ to my ‘buildSrc\build.gradle’, things work ok when I invoke Gradle on the root project (i.e.: the ‘buildSrc’ project is built correctly), while build fails when I try to invoke Gradle from the ‘buildSrc’ folder (i.e.: when I try to clean the ‘buildSrc’ project the correct way)…
What mauromol says, affects IDE integrations as well. That is, loading buildSrc into an IDE requires you to have an approriate build.gradle which doesn’t rely on the implicit ‘apply plugin’. This is a minor issue though as the workaround is trivial.
But I don’t want to build ‘buildSrc’ on its own, I may just need to clean it! If there were a way to do it from the multiproject root project, I wouldn’t be interested in doing it from the ‘buildSrc’ directory. So, it’s certainly an issue.
OK Peter, I understood. However, don’t you agree with me that this is an issue? If I need to clean the ‘buildSrc’ project right now, in certain conditions I must manually delete its ‘build’ directory from the filesystem.
Incremental tasks are good in Gradle, but there are cases in which a clean is still needed. Some examples: incremental compilation does not remove already compiled classes that have been meanwhile removed from the sources, copied files that were removed from the source remain on the target folder until you clean, etc…
Anyway, I’m insisting here because there’s no other way now to report something in your JIRA repository… I still think there’s an issue with the current behaviour.
Gradle doesn’t do incremental compilation (for Java). It’s supposed to handle the case where source files have been removed, and will remove the corresponding class files. The ‘buildSrc’ mechanism is opinionated and has its limitations. If you need to interact directly with ‘buildSrc’, it’s best to explicitly declare a build script. Alternatively, you could have an entirely separate plugin build. At some point, ‘buildSrc’ will be replaced with a more generic, and more powerful, multi-build capability.
