Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard. By default it supports the Google Java Style Guide and Sun Code Conventions, but is highly configurable. It can be invoked with an ANT task and a command line program.
Is there an API in checkstyle to obtain the descriptions of a bug pattern? Background: in Jenkins warnings plugin I am reading and parsing all of your xml files on my own and provide these descriptions using a small method. The drawback is that I need to update my plugin with every release of checkstyle (example jenkinsci/warnings-ng-plugin@199f83e). It would be simpler if I just could increase the version number of a dependency to checkstyle rather than copying files from your distribution.
@uhafner By
bug pattern it sounds like you just want descriptions of properties and/or checks? The only way to retrieve them is by looking at our xdocs, which isn't attached to any JAR as far as I know. You could automate pulling them in like we do validating their existence and types. See https://github.com/checkstyle/checkstyle/blob/master/src/test/java/com/puppycrawl/tools/checkstyle/internal/XdocsPagesTest.java .
we need need somebody to contribute this functionality
there are a lot of talk about this, but do not have enough heads/hands to start working on this
let me know if you are interested to join and start working on this feature
Quick question... We are trying to track the progress of checkstyle reports from one commit to another. We have a nice chunk of technical debt so updating everything right now isn't feasible and one solution we have found is to just commit the report for other tools such as findbugs/spotbugs. The only thing that really changes between builds is the number of issues found, etc, so a new commit would show any newly introduced issues. We were hoping to do this with checkstyles, but it seems that the full path is specified of the file where the violations occur in the report. I wasn't able to find it, but perhaps I'm just missing it. I'd like to change the path of the file to be relative to the build in the report that is produced.
@Singleton06 You can set the relative directory by specifying
See http://checkstyle.sourceforge.net/config.html#Checker_Properties
If everyone's base is different, you can specify it through a system property and have the configuration pick up it's value from there by specifying
baseDir in the Checker configuration.See http://checkstyle.sourceforge.net/config.html#Checker_Properties
If everyone's base is different, you can specify it through a system property and have the configuration pick up it's value from there by specifying
${propertyName}.
Thanks for the help @rnveach
@Singleton06 Yes everyone would have to specify it to give it to the configuration. If your using maven, there may be some magic where it is easier to set it up in the maven config so it happens automatically, but the CLI doesn't know where your base directory is. So someone needs to tell it.
When you say report, do you mean the XML output with
-f xml?
@Singleton06 , if end up with some solution , it would be awesome if you can share it
A lot of people strugling with incremental checksyle validation enforcement
It might be better to create special Filter in our library that take report from previous execution as suppression file
We even can create new AuditListener that generate suppression xml file based on all violations that are found
If you have time to make it happen, we can switch to issue tracker and discuss details
@romani - yeah, that's basically what we're doing, with just a bit more of a manual process. We are checking in the violations and then any updates to that file result in a change in SCM, and we call it out on PRs and things like that.
Setting up a file to be a suppression would be a great idea, but I wonder if it's feasible since changing code around something would cause the lines where the violations that occur to be changed.
interesting. So you could have a build that produces the "suppression" file that could then be fed back into future builds.
I think this would work well. The only thing that I would say that would beneficial with this is to have some way of notifying if there was an unnecessary suppression. It would help to identify situations where an issue has been fixed but the suppression file wasn't updated.
Wouldn’t it make more sense if this incremental feature is one abstraction higher and not in the CheckStyle library? I have implemented such a feature in Jenkins warnings plugin and it works quite well for CheckStyle (and SpotBugs, PMD, etc.). I.e. the CI tool selects the baseline report that can be used to compare the current results with. The delta algorithm has as input the reports of the baseline and the current build (independent of the used static analysis tool) and is capable of producing a report that identifies new and outstanding warnings.
And one note to checkstyle/checkstyle#3242: it would be quite valuable for my warnings plugin if I can visualize all used suppressions. So if checkstyle suppresses a warning it would be a nice additional feature if that would be part of some (additional and optional) report (PMD does this…)
Personally, I think I would prefer that it be part of checkstyle. I think that gives more freedom for other tools to make usage of it. We would like to incorporate it into our maven builds, but wouldn't be opposed to also seeing it in jenkins builds, etc, but it's just not our primary use-case.
Therefore, if I have a way to output a suppression file that would cause a build of that same project to find no violations, that achieves the goal I'm looking for.
code freeze .... while I am doing 8.16 release
====
Hi team, I have a question about the Eclipse Checkstyle plugin. The plugin use ASTVisitor to modify the AST, thus correct the Checkstyle violations. Is it possible to extract these visitors into a separate jar files for distribution? I'm trying to implement a Checkstyle extension in VS Code and I wish I can use these components as part of the dependencies instead of copying the code.
Above is the gif of the POC I have implemented for now
Thank you @rnveach. Are those quickfixers also made by Eclipse? I mean, for example, https://github.com/checkstyle/eclipse-cs/blob/master/net.sf.eclipsecs.ui/src/net/sf/eclipsecs/ui/quickfixes/modifier/ModifierOrderQuickfix.java.