jshiell / checkstyle-idea

CheckStyle plug-in for IntelliJ IDEA
https://plugins.jetbrains.com/plugin/1065-checkstyle-idea
Other
884 stars 160 forks source link

Automatically configure checkstyle plugin based on gradle build #439

Open orionlee opened 5 years ago

orionlee commented 5 years ago

I believe this is essentially the gradle counterpart for #107.

It'd be great if the plugin can honor the existing checkstyle settings in the project gradle build files, at the minimal the checkstyle config files and checkstyle cache.

E.g., configure checkstyle once it recognizes something like the following in the project gradle.

apply plugin: 'checkstyle'

checkstyle {
    configFile = file("${project.rootDir}/config/checkstyle.xml")
configProperties = [
            'checkstyle.cache.file': rootProject.file('build/checkstyle.cache'),
    ]
}

And the android gradle variant (android builds use slightly different config)

apply plugin: 'checkstyle'

task checkstyle(type: Checkstyle) {
    configFile file("${project.rootDir}/config/checkstyle.xml")
    configProperties = [
            'checkstyle.cache.file': rootProject.file('build/checkstyle.cache'),
    ]
// ...
}
jshiell commented 5 years ago

It's a fair request, and probably a useful feature for many people, but it's unlikely to happen, I fear. I haven't used the plugin myself for years, and have just been keeping the lights on. As such, I'm very wary of writing Maven/Gradle/etc integrations and expanding the scope of the plugin even further - Gradle definitely being the scarier option, given the joy of having to parse Kotlin/Groovy, even without supporting all the variants such as Android.

orionlee commented 5 years ago

@jshiell I appreciate your response nonetheless.

staffanf commented 5 years ago

If this would be picked up at some point then it should probably use the tooling-api instead of parsing code it self. My main use case that made me find this issue was that I have started using versioned configs from maven that I resolve to a config file via gradle. Trying to parse something like that form groovy/kotlin would be a lost cause and should not be tried. But I guess that using the tooling-api would work and probably be easier.