This message was deleted.

I am not following you, at the end you get a tree of reports which are accumulative merges based on the configuration output • root (root + foo + bar + baz + qux + quz) ◦ foo (foo + bar + baz) ▪︎ bar (bar) ▪︎ baz (baz) ◦ qux (qux + quz) ▪︎ quz (quz) What am I missing?

What is

root

up there?

it can be potentially anything, that would be based on how your configuration is used

That's the thing, I don't want to manage an extra module + its dependencies. I just want "all the modules in my build"

if you want to get all reports in only one module, you can use the root project, or other project too, I will change the root name as it can mislead because it is the typical use case to use the root one, but it is noy mandatory

Ah, settings plugin yes maybe!

I think this could be a summary

Is that better than using

allprojects {}

from the root

build.gradle

?

I am not pretty sure, but I think that

allproject

is project isolation safe, the project one isn't. But I wouldn't put my hand on the fire 😛

but I think that

allproject

is project isolation safe, the project one isn't.

You mean the settings one?

yeah, the settings one is compatible with project isolation, the project one it isn't (at least in the current state)

Gotcha 👍 TIL !

if you try it and it works, please share feedback here 🙂

Well, we still haven't enabled CC so trying out project isolation might take a while but will do!

hahaha, I feel you!

This is not my case, I have multiple unrelated modules.

Where is the difference actually? If you just want to get the test results of all modules in the build, just use

dependencies { testReportAggregation(allprojects) }

. Whether you do that in a stand-alone aggregator project or in the root project doesn't matter.

I was trying to avoid the

allproject

thing but my this is just over zealous cult to the CC gods from my part 😄

allprojects { ... }

is bad. Using

allprojects

to depend on them for use-cases like this should not disturb CC

dependencies { testReportAggregation(allprojects) }

Welp, that didn't go really far 😞

Cannot convert the provided notation to an object of type Dependency: [project ':apollo-kotlin', project ':apollo-kotlin:apollo-adapters', project ':apollo-kotlin:apollo-annotations', project ':apollo-kotlin:apollo-api', project ':apollo-kotlin:apollo-api-java', project ':apollo-kotlin:apollo-ast', project ':apollo-kotlin:apollo-cli', project ':apollo-kotlin:apollo-compiler', project ':apollo-kotlin:apollo-compose-paging-support', project ':apollo-kotlin:apollo-compose-support',

Oh, that's unexpected. This works in Groovy DSL but not in Kotlin DSL. I guess this should be reported to get improved eventually.

Ah, it's fine to iterate the projects as long as I do not configure them?

Should be, yes

(will file the bug about Kotlin DSL)

Hm, search for it first. It could be I reported it already some time ago. I faintly remember something.

Yep, exactly

I am subscribed to that and I don’t even remember it, it would be fun to check the list of issues I am subscribed

TBH I don't consider this an issue. If Groovy has specific features I don't expect them to work in Kotlin, same as I wouldn't expect to be able to call a Kotlin extension function in Groovy

I do consider it an issue. It is not about "you cannot use Groovy magic in Kotlin". It is about the DSL in Groovy is different from the DSL in Kotlin. And Gradle folks had the goal to have the DSLs at least similar in possibilities. This missing feature is definitely a bad thing imho. 🙂

Gradle folks had the goal to have the DSLs at least similar in possibilities.

Fair point. I can see how that's desirable and a noble goal albeit one I have personally given up any hope to see in a realistic time frame. The turing completeness of both languages and the lack of a common formalism to describe a shared DSL make that effort gargantuous IMO.

Yeah, it looks like a missing API,

Object

magic being checked as

List<Project>>

(or some

List<*>

) on Groovy and not being checked on Kotlin maybe?

Yea, it's using Groovy runtime metaprogramming to flatten the arguments

That's correct, that will not work