Option to fail build if a subproject is included but there is no build file

[anuraaga]

Expected Behavior

Build fails if include points to a path with no build.gradle

Current Behavior

Build succeeds even though the build configuration is broken

Context

It's fairly easy to cause a build.gradle to disappear, most often by moving a folder. If updating settings.gradle is forgotten, it's hard to detect since the build will often continue, the project will be a no-op. While the default behavior probably couldn't be changed, having an option to fail for these cases seems helpful since we can't imagine many if any use cases for include a path that doesn't have any logic.

[anuraaga]

Example of where it crops up

https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/3409/files#r658519847

Luckily the problem won't happen now that I'm switching the build files back to a static name, but previously just because of a misnamed file the tests weren't running at all

[mlopatkin]

We may reconsider it in the future but we don't plan to add anything like that right now.

[ljacomet]

To clarify: a project with no build file is a supported setup even though it is not a recommended one.

[anuraaga]

@ljacomet Things can change for Gradle 8 right? I'd look through a UX lens - very easy to opt into an emtpy build file, even with just a touch command. I suspect that many more users will benefit from failures catching their mistake of missing or wrong named file though.

[ljacomet]

I understand what you are asking but the existing behavior also has reasons. And those are unlikely to go away in Gradle 8 though these are simplifications we might aim for at a later stage.

If you do something like include("services:payment") you are effectively creating an implicit :services project while in your hierarchy it may not have any useful content.
Preventing that would force users to have an empty build file there or change their project setup.
Warning would make such builds much more noisy.