Skip to content
This repository has been archived by the owner on Feb 11, 2022. It is now read-only.

PT-434: Better classes filtering for Findbugs tasks #23

Merged
merged 6 commits into from
Feb 15, 2017

Conversation

mr-archano
Copy link
Contributor

@mr-archano mr-archano commented Feb 15, 2017

Tracked by PT-434

Scope of the PR

While integrating the plugin in one of our projects we realised that Findbugs was analysing a source folder even though an exclude rule was provided for it.

Considerations and implementation

After quite some investigation we realised that the issue is related to the way* we create include patterns from the filtered collection in source. When the source is empty (eg: all the source files have been filtered out) no include pattern can be generated, therefore the collection of classes won't be filtered at all. This sometimes is not a problem because the analysis task is skipped anyway (source property is marked as @SkipWhenEmpty), but this doesn't seem enough to cover all cases.
We decided then to enforce an empty collection for classes when an empty collection is found in source.

Incidentally the task generating html reports for findbugs is now skipped when the related analysis has not run.

Test(s) added

FindbugsIntegrationTest now contains few more tests to check:

  • which :findbug* task has been executed/skipped
  • whether an empty classes property is provided to each findbugs* task with an empty source

(*) Given a Findbugs task we evaluate the filtered set of source files and for each of them we create an include rule for the related class(es).
Let's assume source contains foo/Bar.java; we expect the plugin will produce foo/Bar* as include pattern to allow the Bar.class (and its inner classes) to be included in
the analysis.

@@ -62,12 +62,16 @@ class FindbugsConfigurator extends CodeQualityConfigurator<FindBugs, FindBugsExt
sourceFilter.applyTo(task)
task.conventionMapping.map("classes", {
List<String> includes = createIncludePatterns(task.source, androidSourceDirs)
project.fileTree(variant.javaCompile.destinationDir).include(includes)
}.memoize());
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

During the investigation of the bug I realised that the classes property is evaluated multiple times during the configuration phase of an Android project, so I decided to avoid possible side-effects of memoization.

}

/**
* <p>While integrating the plugin in one of our projects we realised that Findbugs was analysing a source folder
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as great as this information is, do you think the first paragraph helps?

It's an awesome PR description though!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I don't think it adds more insight really. I wanted to put some explanation on why that (gross) task exists tho, maybe I can shave all the context and leave only the hint about the check?

Copy link
Contributor

@devisnik devisnik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

main = 'edu.umd.cs.findbugs.PrintingBugReporter'
standardOutput = new FileOutputStream(htmlReportFile)
args '-html', xmlReportFile
super.exec()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@devisnik devisnik merged commit 4d954b6 into master Feb 15, 2017
@devisnik devisnik deleted the feature/PT-434_findbugs_classes_filtering branch February 15, 2017 15:13
@mr-archano mr-archano mentioned this pull request Feb 16, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants