[Enhancement request] couple of requests for new features

[patpatpat123]

Hello error-prone team,

This is my first post in this repo. I have been using error-prone for half a year now, if not anything else, please allow me to just say thank you for this project.

It is easy to use, and very helpful in finding some corner case bugs.

After half a year of usage, there are some features that we believe might be helpful to the community. Could you please kindly review and consider them?

- standalone maven plugin

As of today, in order to use error prone in a maven project (this is not a maven versus other argument), one needs to do something like this:

 <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <encoding>UTF-8</encoding>
                    <compilerArgs>
                        <arg>-XDcompilePolicy=simple</arg>
                        <arg>-Xplugin:ErrorProne</arg>
                    </compilerArgs>
                    <annotationProcessorPaths>
                        <path>
                            <groupId>com.google.errorprone</groupId>
                            <artifactId>error_prone_core</artifactId>
                            <version>2.20.0</version>
                        </path>
                    </annotationProcessorPaths>
                </configuration>
            </plugin>

This makes it bound to the maven compiler plugin. Would it be possible, like checkstyle, which google invested in, to have a standalone maven plugin, something like:

  <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.11.0</version>
            </plugin>
            <plugin>
                <groupId>com.google.errorprone</groupId>
                <artifactId>error_prone_core</artifactId>
                <version>2.20.0</version>
                <configuration>
                    [...]
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-checkstyle-plugin</artifactId>
                <version>3.3.0</version>
                <configuration>
                    <configLocation>google_checks.xml</configLocation>
                    <outputDirectory>target/reports/checkstyle</outputDirectory>
                    <outputFileFormat>xml</outputFileFormat>
                </configuration>
            </plugin>

And with that, a standalone maven goal, similar to checkstyle:checkstyle maybe errorprone:errorprone (as per your design of course)

(and also, hopefully, to see the needs of .mvn/jvm.config gone. We need to checkin a rather useless file just to benefits from the scan)

- disable analysis on test files, or source code files based on a flag or inclusion-exclusion patterns

As of today, out of the box, the plugin scan the source code, which is great, but also the test files.

It will be great if we can disable the scan on test files, with maybe a flag.

Moreover, it will be great if one can specify exclusion patterns for some specific files not interested in the scan

Report integration with external tools, such as SonarQube, maven site, maven-project-info-reports-plugin, maven reporting

As of today, the output of the scan, and the precious information it contains, are left as it is, within the output of the run. It would be great if it can generate some reports, for historical knowledge, and also, integrate some visualization tools, such as SonarQube, or the maven ecosystem.

I hope not to trouble you guys with my writing, just want to make this error-prone even more interesting.

Wishing you a good day!

Thank you

[Stephan202]

Hey @patpatpat123! I'm not an Error Prone maintainer, so the following is not an official answer, but it may help:

1. Having a separate plugin would be nice, but Error Prone is very tightly integrated with the compiler; the extra plugin would likely have to compile the code a second time around. In all, such a separate plugin would likely not provide sufficient benefit, relative to the new surprises and inefficiencies it introduces.
2. File name-based exclusion of files is possible using the -XepExcludedPaths flag. Since this flag accepts an arbitrary Java regex, with a bit (or a lot :smile:) of fiddling it's also possible to craft a pattern to express "exclude all files but the following", which would effectively amount to an inclusion pattern.
3. On the topic of external integrations it seems best to keep an eye on #3766.

[tbroyer]

I'd also add that to only process non-test code, then configure the maven-compiler-plugin accordingly, e.g. by moving the <compilerArgs> and <annotationProcessorPaths> into an <execution> matching only the compile goal.

https://maven.apache.org/guides/mini/guide-default-execution-ids.html#example-configuring-compile-and-testcompile-mojos-separately

[breun]

A Maven plugin may indeed not provide enough integration, but maybe a Maven extension would allow for enough access to hook into the compilation? Just an idea, I haven't checked the feasibility.