Gradle: Confusion when including Gradle subprojects by file path vs project path

[big-guy]

Consider you have a project like:

root/
   foo/
       sub1/build.gradle
       sub2/build.gradle
   build.gradle
   settings.gradle

This is an accepted, but strange way to include the subprojects:

settings.gradle include ":foo/sub1" include ":foo/sub2"

This adds two subprojects _named_ foo/sub1 and foo/sub2. This causes problems in Eclipse and Sonar because the slash is not allowed in project names.

This happens to work because we convert the project path + name into a file path, which happens to line up with the actual project layout.

I would expect if we fixed this, we would go through a period of deprecated warnings about what values include() accepts. We also have a parallel/similar API for composite builds that always uses file paths (includeBuild()).

We may consider unifying the includeBuild and include APIs to have something similar.

Expected Behavior

I would expect this to fail (invalid project name/path?) or "do the right thing" by converting the slashes into colon path separators.

Current Behavior

Silent, mostly works.

Context

I've seen this come up from time to time since it seems normal to use the file path vs the project path.

Steps to Reproduce (for bugs)

This happens always.

Your Environment

This happens everywhere.

[adammurdoch]

I think we should replace include() with new methods or DSL that make more explicit what kind of value you're providing. For example, use a method name and parameter types that describe this:

includeProjectAt(File dir) // path is inferred from dir
includeProjectWithPath(String path) // dir is inferred from path

Or

includeProject { projectDir = ... }
includeProject { projectPath = ... }
includeProject { projectDir = ...; projectPath = ... }

Or

projects {
    core { projectDir = '...' }
}

Or whatever.

We should do the same thing for includeBuild().

As a separate change, we should deprecate a small number of specific characters that can be used in a project/task/configuration/whatever name, whereever and however that value is specified (which includes the include() method)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[stale[bot]]

This issue has been automatically closed due to inactivity. If you can reproduce this on a recent version of Gradle or if you have a good use case for this feature, please feel free to reopen the issue with steps to reproduce, a quick explanation of your use case or a high-quality pull request.