PitestAggregator doesn't pick up all reports in a multi module project

[NikolayMetchev]

I tried to use the aggregator plugin and it just pulled in 1 submodule instead of everything. It seems the aggregator plugin runs too early.
Not sure if Gradle 8.2 is the problem of if the aggregator is just broken. I have a hacky patch that makes it work locally for me:

Fix_PitestAggregatorPlugin.patch

Perhaps you can make it work in some other way, but as it stands now the aggregator plugin doesn't work for me.

[szpak]

Hmm, we have smoke tests for the aggregator functionality and - in general - it should work. The tests (currently) are not executed with Gradle 8.2, so it might be broken. However, could you downgrade to Gradle to 8.0 or 7.x to check if it is still broken in your project? Maybe there is something else problematic with your project configuration?

[NikolayMetchev]

Please find attached a reproducer.
If you run

 ./gradlew clean pitestReportAggregate --no-configuration-cache --no-build-cache

It will only aggregate the common project and not the alerts-core project.

messaging-pitest-bug.tar.gz

[szpak]

Thanks. I will take a look.

[szpak]

I was able to reproduce the problem and you were right about the reason. I will try to find some "less hacky" fix for that.

[NikolayMetchev]

Any news here?

[NikolayMetchev]

@szpak any luck with a proper fix?

[szpak]

@NikolayMetchev Unfortunately, not. I confirmed the reason (thanks to your sample project!) and even improved the logging to more clearly see that the properties are not set, but I don't have a look idea how to fix it in the prettier :-/.

@Vampire You often have some good ideas about Gradle shortcomings. Maybe you have any proposal for the patch proposed in the issue description could be improved (there is even a reproducer in the 3rd)?

[NikolayMetchev]

Any chance you can apply the hacky patch and create a new issue to clean it up later?

I'm surprised this works for anyone. Not sure what my reproducer is doing that other people will not.

[Vampire]

afterEvaluate is evil in almost all situations. Is most often just doing symptom treatment, shifting problems to a later, more hard to reproduce, more hard to find, and more hard to debug and fix point in time. It is like using SwingUtilities.invokeLater or Platform.runLater to "fix" a GUI problem. The main effect of using afterEvaluate is introducing ordering problems, timing problems, and race conditions. There are very little cases where it is necessary to mitigate some still existing shortcomings.

From a cursory look over that plugin class, the problem is not a Gradle shortcoming, but misusage. You use unsafe cross-project publication, and also access the model of the other projects in the build. Both are highly problematic and even afterEvaluate could fail to fully help.

At https://docs.gradle.org/current/userguide/cross_project_publications.html you can find how to properly do cross-project publication. You can also have a look at the two aggregator plugins that are built-in to Gradle. Those are also using this technique, publishing feature variants with the necessary things and then depending on those in the aggregator project.

[NikolayMetchev]

@szpak any chance this will be looked at? Is my hacky solution possible until you fix it properly?