Apply checkstyle rule UnusedImports

[pankratz76]

I saw the rules are not fully aligned. Assuming the minimum approach will be shared, such as avoiding used ballast as already approached.

• Sync checkstyle rules
• Apply UnusedImports

PS: This is just a suggestion to serve as a basis for discussion—no need to merge this all at once in a big bang. I can also split it up according to priorities (separation of concerns).

[pankratz76]

is this any good?

[bclozel]

I think this PR should stick to its original intent: apply checkstyle rules for imports to the main sourceset.

Can you please add the "AvoidStarImport, "UnusedImports", "RedundantImport" modules to the main checkstyle configuration (not the "nohttp" one which has a separate goal) and only keep the changes required to make the build pass?

[pankratz76]

Yes, of course. You mean the buildSrc/config/checkstyle/checkstyle.xml, right?
I only found the imports when activating the rule in the last remaining src/nohttp/checkstyle.xml.

I don't understand this, as the other two files already have the rule active, so I assume the inheritance is not applied, or I don't get it at all.

check yourself on the recent two commits.

> Task :checkstyleNohttp FAILED

[bclozel]

Sorry I misread the diff in your initial attempt. Import rules were already applied in the main checkstyle configuration it seems. If those don't apply in the framework-docs module there might be a checkstyle suppression rule that does this. Beside finding why those aren't applied in framework-docs, I don't think any other change is required.

[bclozel]

Found it, it's not a suppression rule.
The checkstyle configuration is not applied at all to framework-docs because the conventions plugin is not applied on "framework-*" modules on purpose.

We could manually apply this conventions plugin in the framework-docs module. We might see a lot of issues that don't really make sense from a code snippet perspective, which is what framework-docs is all about.

[bclozel]

I've tried to apply plugin: 'org.springframework.build.conventions' and I'm seeing Kotlin warnings breaking the build already. Our setup requires Java and Kotlin classes with the same name right now. For example, we'd need to suppress warnings for deprecated APIs or remove them entirely from the docs.

Our samples need some flexibility with the code style and I don't think that spending time on enforcing stricter code style in reference docs code snippets is time well spend on our side. I'm closing this PR.