Marc R. Hoffmann

Can you please describe the use case for this? From a first look I see the following issues: * Is this a breaking change of the current behaviour? * No...

It is currently possible. The goal is designed do be used in a separate project for aggregate report generation which lists all modules that should be considered in the aggregate...

Yes, this gives you fine grained control over: 1) The modules that should show up in the report 2) The modules that should contribute execution data (e.g. in case of...

Ok, let's assume we consider transitive dependencies. Question: If you have lot of modules: Which of the module(s) are you going to use for the aggregate-report goal(s)?

Note that when you exclude classes from the agent they still show up in the report -- as not covered. See "Why do I see classes in the coverage report...

While JaCoCo report generation is fast this means you create many redundant reports. Depending on the number of modules and dependencies this could result in some overhead. Do you know...

@mathjeff Thanks for starting working on this! However, before implementing a solution for the CLI we need to clarify the filtering semantics for all our tools. We currently have a...

@mathjeff Change of semantics and backward compatibility both are concerns. I would definitely like to move to class name filtering for all tools in the future (independent of packaging). We...

Currenty JaCoCo processes methods independently from each other. To track the relationships between synthetic methods for lambda bodies and the methods where the lambdas are created we would need to...

@larsgrefer Thanks for the contribution! Do you have some background information about this filter? We're not experts in AspectJ (and I have no practical experience at all): - In what...