This message was deleted.

Have you seen https://docs.gradle.org/current/userguide/jacoco_report_aggregation_plugin.html? I think it's what you're after

thanks. this is some legacy gradle scripts we have which also combines them from multiple android flavors and from that link:

The JaCoCo Report Aggregation plugin does not currently work with the com.android.application plugin.

Whether you collect by accessing the subprojects from root or my accessing the root project from the subs is the same. Both is highly problematic, unsafe, and for sure not project isolation safe. While the JaCoCo aggregation plugin out of the box is not AGP compatible, you can for sure configure it to be, it at least use the same approach, which just is the safe cross project publication approach. I also used the JaCoCo aggregation plugin to do an overall report across test suite types which is not supported out of the box.

food for thought: you can just side step needing to aggregate .exec data entirely if you use an external tool to do it. Though you will still want to make sure the sources/classes of your projects get aggregated/included in the xml report generation. IE: https://github.com/codecov/self-hosted ended up being the ideal solution for us because we run our different test suites in different CI jobs so you never really have a single job where all the coverage data is in one place

oh interesting! thanks @TrevJonez and @Vampire. that now makes more sense. so in a project isolation world, ill look into using the project publication approach. this is down the line, as AGP plugin (8.2.2.) has issues with project isolation anyways so its not like this is the only thing thats blocking me 😆

last time I tried the maven-publish plugin and kotlin plugin were borked too. 😕

yeah the

kotlin-android

plugin i mean more specifically, and the Android studio ide added a gradle file transparently that uses

allProjects

😭

Using proper cross-project publication is not really isolated projects related. Yes, if you use it, that should also be isolated projects safe. But even without project isolation you should use it. Project isolation is highly experimental and you should not really care much for it right now anyway.

The reason I’d want to try it out is because the parallel configuration aspects. Our project takes up to 8 mins to sync in android studio 🫣

And does it help already? I know parallel configuration is one of its goals, but is it done already and helps?

Sorry we already do use —parallel flag. I meant the “This means that Gradle will only configure and create tooling models for projects whose configuration has changed. This work is done in parallel for each project.” Specifically I change a single module import another existing project in the repo and it’s 8 mins later until IDE recognizes it. We’re talking about ~400 modules

The

--parallel

flag has nothing at all to do with that. It is only for executing tasks from different projects in parallel if they don't have an ordering constraint. I asked whether this parallel configuration is already done and cuts down the sync time if you enable project isolation.

Couldn’t get it to pass due to other plugins not being ready for it including android studio inserting Gradle files behind the scenes