I suggest that gradle should fail early in the following cases: - When the settings.gradle includes a non-existing folder - When a subproject has it’s own settings.gradle (as this seems to produce non-useful behavior)
Hey, I have seen both scenarios (having subprojects with a settings.gradle file and letting settings.gradle point to non existing project directories)
One project can have a nested settings.gradle file, because people put two multiprojects build into one on the ci machine, but ran it completely seperated on dev boxes. It would be nice if gradle offers a better way to dynamicallly decide which project sources are available and this won’t be necessary anymore, but at the moment Gradle does not offer that out of the box.
Having projects pointing to empty projects/folders is something else I saw in the past as developers used that to get parallel task execution. Again, this is a nasty workaround to fix a limitation we currently have in Gradle. Once we have parallel task execution this won’t be necessary anymore
So the problem with additional settings.gradle is that those are not supported by gradle CLI. I.e. if you just run ‘gradle xyz’ in a folder with a settings.gradle, then gradle will assume this folder contains the root project. For cross project configuration, you would have to somehow replicate the project structure from the “true” rootproject, recursively. Similarly when running gradle from the project root, the nested settings.gradle will not be evaluated.
If I understand you correctly, what has been done is having multiple level1 gradle root projects with their settings.gradle each, and a root level0 project which has a settings.gradle that either replicates the other settings.gradles, or even loads them manually. This would probably be a very dirty approach since paths like “$rootDir/config” would depend on the execution context, and thus more hacks would be required. I do not know whether it is acceptable in the gradle community to break existing systems with new gradle minor versions if they have relied on unspecified behavior.
A nicer approach would be to create a suitable defined behavior for this use-case and deprecate the existing behavior such that only a deprecation warning is printed when a subproject has it’s own settings.gradle. Another approach would be to have opt-in strictness (like cmake policies) or opt-out strictness such that breakage with a new gradle version can be easily repaired.
I do not understand how empty projects would help with parallel task execution. If you can give more details on this use-case I can try to think of something better.
In any case warnings can be implemented hopefully without annoying gradle users, as a first step. I can look into creating a pull request.