Add a new Mojo ("report-aggregate-all") to aggregate projects from reactor without forking a lifecycle

[olamy]

• Add option to aggregate automatically reports from aggregators, no need to add any dependency

Actually having some aggregated report, need to have a module and include all dependencies of the current project.
This doesn't scale very well for large projects (Jetty can have up to more than 300 modules, we can't really add and maintain a pom with all other modules included)

[olamy]

@Godin Hi any chance to get this merged and released?

[olamy]

with recent version of Maven this can be build before the maven plugin, so need to be sure the maven plugin is build first.

[sbordet]

Why is this property called only... and not all...?

From the javadoc seems more appropriate to call it allReactorProjects, or perhaps allModules or allSubModules?

[olamy]

I was not really sure because the code currently reads only all dependencies declared in the coverage/aggregator project (dependencies that are part of the reactor).
If the flag is activated, the code will not use any current protect dependencies but only(All :))ReactorProjects.
So yes, something like allReactorProjects would also work, except it doesn't tell the user the configuration no longer reads the project's dependencies.
Doh, this looks complicated to explain so that it might be wrong :).

no real strong opinion. @Godin what do you think?

[olamy]

@Godin ping

[olamy]

@Godin any chance to have this merged or at least some comments on why this cannot be merged?
Thanks

[cpfeiffer]

Thanks a lot, we had a similar thing in mind. However, I would like to suggest creating a new mojo for this, and making it an aggregator mojo (aggregator = true).

Reason: when adding the goal to a maven command like this:

mvn clean
mvn verify jacoco:report-aggregate

you will successfully get a toplevel jacoco-report that includes all modules, however with no content at all. This is because
non-aggregator mojos are integrated into the normal build lifecycle. So the report for the toplevel module will be created before any coverage has been calculated for the modules.

Even worse, if you call

mvn clean verify jacoco:report-aggregate

you do get coverage, alas, the coverage of the previous build, because clean is also integrated into the lifecycle. So when report-aggregate is executed on the parent, it will find the old *.exec files of the child modules, because they have not been cleaned, yet.

A dedicated aggregator-mojo OTOH will be executed after the lifecycle:

mvn clean verify jacoco:report-aggregate-all

This would also remove the need for the onlyReactorProjects property.

[olamy]

@cpfeiffer Sorry for delay, I forgot this one. The changes should be better.
I have been testing it on large projects such as Jetty codebase and Cometd.

[cpfeiffer]

Awesome! Would it be good practice to let ReportAggregateAllMojo inherit ReportAggregateMojo and just overriding the findDependencies() (to be made protected then)?

[olamy]

Awesome! Would it be good practice to let ReportAggregateAllMojo inherit ReportAggregateMojo and just overriding the findDependencies() (to be made protected then)?

Oh right. good catch, 2 ezy. Just pushed it.

[cpfeiffer]

Excellent, thanks a lot! ❤️
So what do the the jacoco maintainers think?

[olamy]

@Godin ping :)

[olamy]

sadly, this doesn't look to attract any attention from the maintainer of the jacoco plugin.
Not sure why, as it's a real missing feature.
I will have to create a separate Maven plugin with only this single mojo. BTW a bit different as I will not be able to use exact same code which extends a mojo from here.

[cpfeiffer]

sadly, this doesn't look to attract any attention from the maintainer of the jacoco plugin. Not sure why, as it's a real missing feature. I will have to create a separate Maven plugin with only this single mojo. BTW a bit different as I will not be able to use exact same code which extends a mojo from here.

I hope it's just a time-issue.
This fix would make a whole wiki-section of discussion/workarounds obsolete. I would be willing to update it. What do you think, @Godin ?

[olamy]

Maybe a timing issue for an idea/PR started 6 months ago...

[olamy]

@cpfeiffer If you are interested, I have done this https://github.com/olamy/jacoco-aggregator-maven-plugin/
It's not the best solution, but after more than six months and no comment from here, I guess there is no interest.
I will leave the PR open just in case.

[marchof]

Dear @olamy, thanks for your contribution and very sorry for the silence from us maintainers. We (especially @Godin) mostly spend our spare time in keeping the core up-to-date. Due to our limited resources we're very reluctant to add new features which requires even more maintenance. Especially maintaining the Maven plugin is very exhausting as many community members have a strong opinion how things are done (at least in their context). We were already at the point to give-up on the integrations so that that the community can start separate projects.

Questions: Can you imagine to help us with the maintenance (bug fixing, feature/bug triage etc) for the Maven goals in the long run?

[olamy]

@marchof, thanks for your comment and for answering a big part of my frustration :)
No worries. I perfectly understand you may have limited time for maintenance.
I am happy to help maintain the Maven plugin part, as I may have some experience doing so.
Thanks

[olamy]

@marchof @Godin thanks guys for your help and merge it for the last release 0.8.13.
very good community support here.........

[marchof]

@olamy As I explained above we prioritize maintenance and regular lifecycle tasks over new features. As Java 24 was released we had a strong demand by the community to have released JaCoCo version which support the latest Java release.

Spending spare time on a free project only works in a friendly and respectful environment. While I understand your frustration that we haven't found time to review your PR I politely request to refrain from passive agressive statements.