Using the new PI-isolation

project.gradle.lifecycle.beforeProject {}

is there a way to do the usual trick of aggregating all projects into the root project? I can add a plugin to every project. But how do I collect the list of all projects to add as dependencies to the root project?

I believe this is the way: https://www.liutikas.net/2024/12/11/Together-In-Isolation.html

I am also wondering about this. I was thinking that there shouldn't be something like

isolated.subProjects

or

isolated.subProjectPaths

or/and

isolated.rootProject.subProjects

. The information provided should be the project names/paths as these are fixed after the initialization phase. The article uses the traditional

subprojects { }

block, which I assume is still allowed as long as you do not call any methods on the subproject object (

this

in the example in the article). But it does not feel like this is a good solution on the long run (?)

This is what I ended up doing and I think it's working:

override fun apply(target: Settings) {
        target.gradle.lifecycle.beforeProject { project ->
            if (project.rootProject == project) {
                project.pluginManager.apply("com.gradleup.nmcp.aggregation")

                project.subprojects {
                    project.dependencies.add(nmcpConsumerConfigurationName, project.dependencies.create(it))
                }
            } else {
                project.pluginManager.apply("com.gradleup.nmcp")
            }
        }
    }

The general guideline is that anything that’s immutable after settings have executed is safe to access even across projects. This is true for things related to project identity, such as name/path and even the project directory. This is also true for the project hierarchy structure as a whole — it’s safe to iterate over the projects via

subprojects

and such, as long as you only touch immutable project state of other projects. Establishing dependencies between projects also does not require anything except project identity, so it’s safe too.

> the use case of cross-project aggregation and potentially come up with a more first-class solution. I'm concerned that we are focusing too much on the

subprojects {}

aggregations and potentially missing a more flexible cross project API. I managed to do what I want with the

subprojects {}

block above but this comes with a big caveat that my aggregation now needs to use

lenient(true)

. This is making me quite uncomfortable. I've been hit a couple of times already with resolution errors (bad artifact being resolved, undetected misconfiguration, etc...).

This is making me quite uncomfortable. I’ve been hit a couple of times already with resolution errors (bad artifact being resolved, undetected misconfiguration, etc...)

Can you describe your use case from the user experience you expect? For instance, does it mean, you’d like a mechanism that fails fast, instead of silently skipping “non-producing” projects?

Yes, fail fast is almost a requirement IMO. Also listing dependencies shouldn't list irrellevant projects, etc...

Why do your need to use

lenient

? It ignores any error that could arise. Without

lenient

, the artifact view should still only give you those that have the variant but not fail on non-producing projects, at least it you set any attributes. (https://github.com/gradle/gradle/issues/27773 / https://github.com/gradle/gradle/issues/30314)

In my case, what I’d like is that the subproject plugin can add its own project to a known-in-advance root project (doesn’t have to be the root project but root is probably the simplest mental model). I don’t think this is currently possible?

If by “add” you mean adding a dependency, then it’s not possible. Isolated Projects come with a promise of safe configure-on-demand and incrementality. If a subproject was allowed to contribute anything to a mutable container of a parent (e.g. a dependency on itself into the root project), then the build result could be different depending on whether that subproject was scheduled for configuration or not (e.g. when running a qualified task like

:myRootTask

). In other words, unless the root project (or any project with the aggregating logic) does not explicitly request something from the subprojects, those might not be configured at all.

Without

lenient

, the artifact view should still only give you those that have the variant but not fail on non-producing projects, at least it you set any attributes.

TIL, thanks @Vampire! This is good to know but also reinforces my impression that these APIs are more complicated than need be.

Maybe you then need to register the dependencies manually and have some verification that you didn't forget any? For example the sub-project writing to some shared build service that they should be included in the root project and then in the root project check whether all in the service are added, which will then at least be detected in a full build on CI?

That would be better than no verification (at least the user would get a nice error). But still not the endgame I'm looking for (the user would have to configure things in only a single place and the project graph doesn't contain unused/wrong edges)

But then isn’t what I’m doing with

subprojects {}

and adding all the projects to the root dependencies essentially just killing any configure-on-demand benefits?

Possibly, but this would be only for this case, when you do expect to aggregate things across all projects. It doesn’t mean that other builds that don’t do a similar thing shouldn’t benefit from configure-on-demand. Moreover, even in that case you should still be able to run a task only in a subproject (aka you don’t need the aggregation for that invocation), and not pay the price of configuring all sibling subprojects.