https://gradle.com/ logo
Join Slack
Powered by
Hey folks, We’d like to reach out to the community...
# community-support
a
Hey folks, We’d like to reach out to the community on the topic of the root project accessor generated by 
TYPESAFE_PROJECT_ACCESSORS
 Today, Gradle generates a named accessor for the root project, which causes various problems. It looks like this:
Copy code
// setttings.gradle.kts

enableFeaturePreview("TYPESAFE_PROJECT_ACCESSORS")
rootProject.name = "myproject" // <---- some name has been assigned to the root project
include("lib")


// lib/build.gradle.kts

dependencies {
    implementation(projects.myproject) // <---- notice the "type-safe" access to the root project
}
Do you know of existing use-cases for this part of the feature? It seems reasonable to deprecate and remove it, because there are at least two ways to achieve the same thing:
Copy code
implementation(rootProject)
implementation(project(":"))
Share your use-cases here, or comment on the issue: https://github.com/gradle/gradle/issues/24295
v
I would vote to keep the accessor, as it is imho more consistent. Using 
rootProject
might not be project isolation safe? But at least not consistent with the other project accessors. And 
project(":")
is for me not an argument, because then you also just not use type-safe accessors, but just use 
project("lib")
. I don't know why one should name the root project and a subproject the same.
a
I would vote to keep the accessor, as it is imho more consistent.
Are there any other arguments in favor of this apart from the consistency?
Using 
rootProject
might not be project isolation safe?
It is safe, because no mutable cross-project state is access when setting up a dependency
v
Are there any other arguments in favor of this apart from the consistency?
Not right now from me, not used them too much so far. But when I use it, I would expect to have an accessor for the root project 🙂
Not sure what other problems you referred to. That the accessor is not regenerated if the name changes is imho just a bug. And naming the root project the same as a subproject, I personally consider a build bug anyway, no matter whether the accessors are used or not. 🙂
a
And naming the root project the same as a subproject, I personally consider a build bug anyway, no matter whether the accessors are used or not.
Well, it seems a non-trivial number of people would disagree https://github.com/gradle/gradle/issues/16608
v
Quite possible. 😄 I also would never use empty root project and just one subproject, that just feels wrong to me. If I only need one project, I don't make a multi-project build. Imho, one could also say "If you want to use project accessors the names need to be unique". In those cases it would probably be trivial to just append 
-project
to the root project name or similar, especially if it just is an empty project anyway. 🙂
But maybe it could also be made configurable by some Gradle property that disables generating the accessor for the rootproject or similar to satisfy that pattern. 🤷‍♂️
a
I think it's confusing that there's 3 different ways to depend on the root project (
implementation( project(":") / rootProject / projects.myproject )
. I think that 
implementation(rootProject)
is really strange. 
rootProject
is usually used for configuration, or accessing configuration, and never for adding a dependency. I guess it makes sense technically, but it's conflating a couple of concepts. It's not easy to discover. I have the same opinion for 
implementation(project)
- which is sometimes needed, e.g. for JVM test suites. It's confusing. I much prefer using the typesafe accessors. They're similar to the version catalog. I would like it if they were promoted as a default. I agree it's important to fix the `projects.myproject`/`projects(":myproject)` same-name clash. However, I would prefer to see a different solution, so that the typesafe accessors can be used consistently, and so it's conceptionally simpler to add dependencies. The DSL should also be easier to discover and understand. • Remove the generated accessor 
projects.myproject
• Add a generated accessor the root project 
projects.rootProject
(a shortcut for 
project(":")
, only to be used for declaring dependencies). • For convenience/symmetry, add 
projects.currentProject
(a shortcut for 
project(project.path)
- again, only for declaring dependencies). And I'd go one step further and deprecate adding dependencies via 
implementation(rootProject / project)
. Dependencies should only be added via string coords, version catalog entries, typesafe project accessors, and 
project(":path")
(which should eventually be phased out).
a
Thank you for the detailed input!
• For convenience/symmetry, add 
projects.currentProject
(a shortcut for 
project(project.path)
- again, only for declaring dependencies).
What is the use case for this part?
a
The use-case for declaring a dependency on the current project? One example would be for JVM test suites. This looks weird:
Copy code
testing.suites.register<JvmTestSuite>("integrationTest") { 
  dependencies {
    implementation(project()) 
    implementation(projects.fooProject) 
    implementation(project(":barProject")) 
    implementation(rootProject) 
  }
}
This might also look weird, but at least it's consistent!
Copy code
testing.suites.register<JvmTestSuite>("integrationTest") { 
  dependencies {
    implementation(projects.currentProject) 
    implementation(projects.fooProject) 
    implementation(projects.barProject) 
    implementation(projects.rootProject) 
  }
}
a
Could you create a separate issue for this?
a
sorry Alex, I'm not exactly sure what the issue should be so I'm not comfortable making one - feel free to copy/paste my responses though!
v
Probably "Please create projects.currentProject accessor with type-safe project accessors" 🙂
a
@Adam, the issue is just that: you have a use-case for the type-safe project accessors that is not currently supported Your previous message is a good chunk of the content already 👍
17 Views
Open in Slack
PreviousNext
Powered by