Open patpatpat123 opened 1 year ago
Hey @patpatpat123! I'm not an Error Prone maintainer, so the following is not an official answer, but it may help:
-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.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.
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.
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:
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:
And with that, a standalone maven goal, similar to
checkstyle:checkstyle
maybeerrorprone: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