For Isolated Projects (which we are far, far away from using, but I’m trying to write new plugin code “correctly”) - is the idea that since you can’t access the extensions/properties/other state of other projects, every exchange of information between two project should happen through resolving a

Configuration

with custom attributes a la https://docs.gradle.org/current/userguide/cross_project_publications.html#sec:variant-aware-sharing? Or is there some other way to safely read data from other projects?

a BuildService can work, but can be delicate https://docs.gradle.org/8.13/userguide/build_services.html

You can read

Project.name

but that's about it 😅

mm, I think with the build services feels like there may be timing issues? ie a project gets evaluated after another, doesn’t register the right info in time?

build services always get me a bit itchy too but I have never really investigated much deeper given that the

Configuration

dance usually works for my use cases

I think with the build services feels like there may be timing issues

It depends on what data you want to share. It will be fine if the BuildService just collects data using the Provider API, and the data is only computed during task execution.

mmm, I’m currently trying to build something where project A needs to use some information in projects that are dependents of project A (ie the other projects that depend on A). I was trying to do something crazy with lazily computed attributes, but a build service with a lazy map (with project paths a keys) might work too, provided all projects are actually evaluated

the problem with BuildServices is they mandate the buildscript classpath is identical for all buildscripts.

Good old https://github.com/gradle/gradle/issues/17559

re: the buildscripts, we enforce they’re all the same anyway, it’s such horrible errors/debugging when they’re different

it's not that all projects need to have the same buildscript classpath necessarily, but the buildservice must be in a shared parent. I dont' see how you'd run into issues if you register it in a root or settings plugin

I’m currently trying to build something where project A needs to use some information in projects that are dependents of project A (ie the other projects that depend on A)

I've given up on having a "smart" way to do this, I force my users to declare the two way dependency

yeah, I’m aware this might not make sense;

I’ve given up on having a “smart” way to do this, I force my users to declare the two way dependency

Ideally they would, unfortunately there are ~4000 repos and 1000 users to deal with, so need to do something automatically

I'm curious if you find something. To my last understanding, this was just not possible

I’ll keep you updated. I think I might be able to do it, but it feels if a project is ever not evaluated (eg Configuration-on-demand, which seems like Isolated Projects will eventually make “safe” - our monorepo owners crave it) might cause issues

Yea, exactly, feels like BuildService can't force task dependencies...

nice, this is my exact problem

I don’t know if it is a correct api, but there is a new Flow api: FlowAction etc., but there is no real documentation and the jacadocs are not real helpful (only about playing a song…). But I never used this api.

https://github.com/gradle/gradle/commit/995776f68500ded7e3e3f123787d20af91644d6d 2 years ago 😅

Yeah, and there is only 1 event, the end of build event 🤷🏻‍♂️ very strange

TIL another API in Gradle

But I usually also use all the configuration pain and plain old files to pass data. On the other hand, this will also work out of the box with published artifacts, so refactoring a (mono) repo is possible.

True, it's a forcing function of making it work with external dependencies

we use FlowActions extensively for doing an action at the end of build (basically replacing the build finished listener that is deprecated) - I’m not sure it has more real uses beyond replacing the old build listener api?

We plan to introduce more Isolated Projects-safe APIs to share data across projects. It’s still in the early design phase and not in focus at the moment, but it’s something we definitely want to improve. Umbrella issue: https://github.com/gradle/gradle/issues/25179

I do notice that it’s possible to enumerate other projects and declare a dependency (with appropriate attributes) on each, but I don’t notice an easy way to filter to just projects that create the given artifact. We can set

isLenient(true)

this is basically what I’m trying - if there was a built in way to do this, it would be great

Unfortunately, it’s the only IP-safe way for now.

> In other words, would the aggregation use-case cover your needs? @Alex Semin I feel like looking at it from the aggregation point of view is very limiting. Aggregation is a particular case of a more general problem

Talking BCV + publishing examples, aggregating accross all projects feels bad, what I want is individual project to register themselves to the “root” project: not all sub-projects want to publish or track their API

What is BCV? What are you trying to achieve by letting individual projects register themselves in the root?

Binary Compatibility Validator

But how do you know what project will publish without configuring them?

Good point.

That is correct

Yeah, and for this reason you could use lenient=true

But this should be fine. "Just" make it easy to cache and reuse the project graph

Isn’t project graph = configuration cache?

The CC stores the task graph iiuc