The new

TYPESAFE_PROJECT_ACCESSORS

has one strange thing. It generate type safe accessor also for root project folder, why? When you then try to run such project on TeamCity it fails with

org.gradle.api.InvalidUserDataException: Cannot generate project dependency accessors:
  - Cannot generate project dependency accessors because project '55cb9b3dea7c8b39' doesn't follow the naming convention: [a-zA-Z]([A-Za-z0-9\-_])*
Watched directory hierarchies: [/Users/teamcity/buildAgent/work/55cb9b3dea7c8b39]

Because root project folder is 55cb9b3dea7c8b39 in this case. For me doesn't make sense to make project dependent on the folder name where project was checkouted. It can be anything.

you are missing

rootProject.name = "..."

in your

settings.gradle

file. Always set a root project name, or it will, as you noticed, be inferred from the directory name, which usually doesn't make sense.

Thanks. Interesting. In one project makes sense to use

rootProject

, without specific name. But how can other projects reference my root project?

projects.foo

?

There is a community request to stop generating a root accessor, though https://github.com/gradle/gradle/issues/24295

that's IMHO a bad idea

Why?

because there's no reason to exclude it. The root project is a project like any other, it needs to be addressable via an accessor like other projects. There's no reason why it would be the only one which would require the

project(":")

notation. See also my explanation above.

The root project is a project like any other, it needs to be addressable via an accessor like other projects.

The goal of completeness here goes against ergonomics and consistency. Accessors are about explicitly referencing a project and

rootProject

is always there. There is also a problem of placement. The logical place (for completeness) is to put the root project at the very top of the accessors call hierarchy. But that introduces an unnecessary step to the access of any sub-project. The current design places it on the same level as first-level children, which already hints at complications. I would also consider today’s Gradle best practice of having a “subproject” even for a single-project builds. Aka having

app/build.gradle

structure, instead of just

build.gradle

. More so in the actual multi-project builds.

that could be seen as an authority argument, but I wrote the code about project accessors. It doesn't go against consistency IMHO, quite the contrary.

rootProject

is not a

Dependency

, it's a

Project

.

projects.rootName

is the strict equivalent to

project(":")

, not

rootProject

.

I was aware that you are the author. It’s fair that the types are different. Though, I believe the

rootProject

can be used to declare a dependency all the same, no?

I don't know if this changed, but when we discussed this, the fact that you can declare a dependency using a

Project

instance is historical and probably not something that you'd want (because it leaks state). Similarly the methods which work on

Dependency

wouldn't work (e.g variants).

The inconsistency I was point out was not about the types, but about the hierarchy layout. The first level will contain all root’s children and the root itself. This is not true for any other level of the hierarchy. It also duplicates the hierarchy, as all projects are reacheable through the main

projects

accessor as well as through the root project accessor.

yes, I agree about this one. However we had discussed this back then and it was deemed acceptable. The types inconsistency and the fact that there would be no accessor for the root project is worse imho.