Violations' module is inaccurately set when checkDependencies is set to true in Lint

[lamphamTL]

trafficstars

Description

module property in Violation and Violations is set to the project ('s path) where lint is executed. This works well when lint (and any other check) is run separately from each gradle module. However, when we enable checkDependencies (this is a recommended approach to improve lint performance), lint is run also in child modules, whereas all violations' location will always be set to the parent module.

Expected behavior

• Violation's module is set to the module where the violation code is located.

[TWiStErRob]

Thanks for the report.

That's an interesting problem. I wonder if we have information available, as when we run just one lint, the report task only runs in one module I would think along with many analyze ones. So there might be no way to distinguish where each violation is coming from.

I think one thing to ponder is whether you actually need this plugin when you use checkDependencies? At that point the default report is already a single file. Which was the goal of this plugin when it was created before their big AGP lint analyze/report task refactoring.

[lamphamTL]

So there might be no way to distinguish where each violation is coming from.

There's the location which may help reluctantly deduce the gradle project?

whether you actually need this plugin when you use checkDependencies

Yeah I agree for general purpose we won't need this tool too much when running with the option checkDependencies. However, in our case, we have used this and have been used to this report's format, there's no harm keeping it (especially the original report of lint doesn't propose the gradle project information either), only adds up few second to the build duration

[TWiStErRob]

I had a look and reproduced the problem. Made a quick attempt at validating the deduction and I don't like it. That said, pragmatically it makes sense as it's very annoying to associate the issue with the app module when there are potentially hundreds of modules. ~I'll have a look at what effects it has on de-duplication.~ Edit: Deduplication wasn't working before either (same finding was associated with submodule and app module), so it's not worse.

Original: reports.zip With inference: reports.zip

[lamphamTL]

The report looks great to me. I hope you already handle specifically the variantName of child modules (instead taking the one of the parent app module which may contain build flavor)