PMD design to integrate our solution

how renderer and filters are configured through Ant and CLI.

I would compose a renderer using a name convention (e.g splitting names by ":"). Moreover, it is necessary to modify how properties are handled to distinguish between the properties of different renderers. It is also required validate correct compositions.

pmd pmd -d . -f git:xml -P git.property=xxxx -Pxml.property=yyyy -R ruleset.xml

how the filter detects what is new code to be analyzed.

First it is needed to detect if the analyzed file, has been changed.

git diff ${last_analyzed_commit} ${file_with_issues}

The problem is to resolve the last analyzed commit, which should correspond to the last fetched commit or the last push we made. This information appears when we resolve

git rev-parse origin/{current_branch}

However, if we are working creating a feature per branch, this should be parametrized from the CLI (-P "git.ref=master") or resolved by the repository where we store our last analysis.

Clearly, those issues that appears in modified lines should be reported. However, there are some PMD rule violations, like "Avoid unused local variables" which appear always on the place where a symbol is defined (method, class, variable..). Therefore, if we drop some lines of code and we forget to remove a variable declaration, this violation should appear, right? But if we are purely filtering issues according the commit of the line we touch, it will never appear because we have not modified the line where this variable is defined.

Consequently, we need to check for those issues that belong to untouched parts of code, if already exist or not in our last analysis. In order to retrieve them, I use httpclient and gson libraries. Afterwards, we need to calculate the corresponding line for our current file revision to certainly identify which already appeared.

clear identification of trade-offs being made.

In order to be completely extensible and customizable, filters also needs an interface to use to ask for data related to the last analysis. However, we could define a default behavior without it. It can be useful in most of the cases, but the problem I have described appears. I would use the same approach to specify it in the cli (git:remote:text).

A part from it, to become extensible to other control systems, we should have an abstract class for filters for versioning (Git, SVN, Mercurial) whose implementation should resolve them with the appropriate commands or libraries.