Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve baseline-checkstyle implementation and upgrade to 8.12 #313

Merged
merged 2 commits into from
Aug 13, 2018

Conversation

robert3005
Copy link
Contributor

@robert3005 robert3005 commented Aug 2, 2018

@iamdanfox

fixes #207
fixes #198

@robert3005 robert3005 requested a review from a team as a code owner August 2, 2018 03:33
project.getTasks().withType(Javadoc.class, javadoc -> {
if (project.getConvention().getPlugin(JavaPluginConvention.class)
.getSourceCompatibility().isJava8Compatible()) {
javadoc.options(minimalJavadocOptions -> ((StandardJavadocDocletOptions) minimalJavadocOptions)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

this is really annoying but looks like the api is a little bs here

Copy link
Contributor

Choose a reason for hiding this comment

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

If the if statement is always going to return the same value, could we move it outside the withType(Javadoc.class, -> bit?

project.getTasks().withType(Checkstyle.class, checkstyle -> {
// Make checkstyle include files in src/main/resources and src/test/resources, e.g., for whitespace checks.
checkstyle.source("src/main/resources");
checkstyle.source("src/test/resources");
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it worth iterating through sourcesets here? Repos commonly add integTest too

Copy link
Contributor

Choose a reason for hiding this comment

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

there's like an ordering problem here ...

*/
public final class BaselineCheckstyle extends AbstractBaselinePlugin {

private static final String DEFAULT_CHECKSTYLE_VERSION = "8.11";
Copy link
Contributor

Choose a reason for hiding this comment

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

I guess we should probably cut and RC so that we can try out the 7.5.1 -> 8.11 upgrade on a few internal projects?

Copy link
Contributor

Choose a reason for hiding this comment

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

want to go straight to 8.12?

@iamdanfox
Copy link
Contributor

So just to double check, this PR is essentially:

  1. convert groovy -> java
  2. upgrade checkstyle 7.5.1 -> 8.11
  3. remove some afterEvaluate
  4. remove workaround for now fixed Checkstyle classpath is set incorrectly for multi-project builds gradle/gradle#855

@robert3005
Copy link
Contributor Author

Yes, I am trying to go through some of the plugins here and make them more modern/conforming to current practices.

The checkstyle bump is here since in #205 we expressed desire to do so and we never did overall and current version is 1.5 year old now

@uschi2000
Copy link
Contributor

Repeating my question from #205 :

There's a pretty big change list between 7.5.1 and 8.1. Did you go through them and verify that (1) we're comfortable with the changes, (2) they align with our Baseline docs, (3) they are compatible with the IntelliJ and Eclipse formatting, (4) they require no other config change?

.setConfigDir(project.file(Paths.get(getConfigDir(), "checkstyle").toString()));
project.getTasks().withType(Checkstyle.class, checkstyle -> {
// Make checkstyle include files in src/main/resources and src/test/resources, e.g., for whitespace checks.
project.getConvention().getPlugin(JavaPluginConvention.class).getSourceSets()
Copy link
Contributor Author

Choose a reason for hiding this comment

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

need to verify this is the correct path

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is the correct path though it's impossible to test in unit tests. Will add an integration test

@robert3005
Copy link
Contributor Author

robert3005 commented Aug 2, 2018

Run this locally - need to update some checkstyle config to match new values.

Things I found that are different:
SummaryJavaDoc - your javadoc needs to have a summary sentence - sounds like a good change
UnnecessaryParentheses - now catches unnecessary parens for lambda arguments - good as well
ImportOrder - Doesn't allow empty line between import static and import - should we change it or not?
DesignForExtension - catches violations in tests that weren't previously being caught - might want to suppress for tests

@robert3005
Copy link
Contributor Author

The DFE thing is only because the repo I looked at is using junit5 and defaults don't account for it

@robert3005 robert3005 force-pushed the rk/checkstyle branch 2 times, most recently from e4300cd to 62131be Compare August 3, 2018 02:51
@robert3005
Copy link
Contributor Author

After adjusting the checkstyle config to match what we expected before I get only SummaryJavadoc and UnnecessaryParentheses violations which look like good changes and could be considered bugs in checkstyle overall

@@ -433,6 +433,10 @@
<property name="format" value="^[a-z][a-zA-Z0-9]+$"/>
<message key="name.invalidPattern" value="Parameter name ''{0}'' must match pattern ''{1}''."/>
</module>
<module name="LambdaParameterName"> <!-- Java Style Guide: Parameter names -->
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Adds parameter name checkstyle for lambda parameters. There's issues with ParameterName right now for lambdas that it doesn't correctly detect lambdas (and after applying this I can confirm that I have few violations of lambda parameter names that weren't caught before). From 8.12 checkstyle ParameterName will completely ignore lambda parameters and this check is preferred.

Copy link
Contributor

@ferozco ferozco left a comment

Choose a reason for hiding this comment

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

LGTM, lets cut an RC and test this out in a few places before rolling out more widely

@robert3005
Copy link
Contributor Author

@uschi2000 how do you feel about the current state?

@uschi2000
Copy link
Contributor

Looks good, thanks @robert3005 . Can you include the 8.11/8.12 bump in the commit message, please?

@robert3005 robert3005 changed the title Better checkstyle plugin implementation Improve baseline-checkstyle implementation and upgrade to 8.12 Aug 13, 2018
@robert3005
Copy link
Contributor Author

We're going to remove LambdaParameterName from the rules since in practice we found way too many violations for this rule to be meaningful

@robert3005 robert3005 merged commit 5375154 into develop Aug 13, 2018
@robert3005 robert3005 deleted the rk/checkstyle branch August 13, 2018 19:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

checkstyle.xml rules don't work with checkstyle 8.1 Design for extension is absurd for test methods
4 participants