Typesafe project accessors not working in root build script file

[elect86]

The new accessors do not work in my root build script file.

If I test them in the corresponding subproject script, then it's fine.

Current Behavior or error

The accessors are actually properly generated, but as soon as I try to use them, then the sync fails:

Extension with name 'projects' does not exist. Currently registered extension names: [ext, defaultArtifacts, sourceSets, reporting, java, javaToolchains, kotlin, kotlinTestRegistry, shadow, publishing]

Steps to Reproduce

Clone this branch and sync

Your Environment

7.0 rc1 bin
Build scan URL

[tbroyer]

Looks to me like it's the same cause as for #16634, where the problem seems to not be the "root build script file" per se, but actually subprojects' blocks inside that file (either subprojects {} or project(":foo") {}). The Kotlin DSL extension property then applies to the subproject's Project instance that's this in the block, and not to the root project; so a workaround would be to use rootProject.projects.core.

[melix]

Yes, @tbroyer is correct. Nowadays it's considered a bad pattern to reach out to other project's state using allprojects or subprojects. In particular here to declare dependencies. It's better to have the dependencies declared in each project separately. If it's to avoid repetition, you have 2 options:

1. use a bundle and declare the bundle as a dependency, for dependencies which are declared on the same configuration
2. use convention plugins to declare the dependencies (in which case, unfortunately, you wouldn't be able to use typesafe accessors)

[elect86]

Uh, ok

but why is considered bad pattern?

[melix]

There are different reasons. First it makes it difficult to decouple projects. Say you want to extract one project in a composite build, or even its own repository. If you apply cross-configuration like this, it's difficult to do.

Second, if you open a build script of a project, it's difficult to figure out what has already been configured. For example, if I open foo/build.gradle and that you see:

plugins {
   id 'java-library'
}

it's immediately obvious what the project is and what plugins are applied to it. We can reason about it. Except if you do cross-configuration, because then, any other project can mutate the state of this project, add more plugins, and you would never know. In the end the build breaks and it's super hard to figure out why. In other words: keeping the plugins {...} block sane is important as it provides insights about what is applied to a project.

Another reason is ordering. By applying cross-configuration, you can never really know when something is going to be configured, which often implies dirty workarounds like afterEvaluate. Worse, the behavior will be inconsistent if you use configure on demand or not.

Last, there's a performance and isolation aspect: by doing cross-configuration it prevents the engine from doing some optimizations. With the configuration cache we're moving away from this pattern, as it allows us to reason project per project and therefore enable optimizations like intra-project parallelism by default.

[melix]

We don't plan to fix this short term. We discourage use of cross-configuration and there are 2 workarounds:

1. use rootProject.projects to access the catalog
2. use the Groovy DSL instead, in which case it doesn't matter if the extension exists or not

[TWiStErRob]

@melix is this subprojects anti-pattern documented somewhere in detail? (even a blog)