jeremymailen / kotlinter-gradle

Painless, fast ktlint plugin for Gradle

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Documentation wrong on customizing tasks

dalewking opened this issue · comments

The groovy and kotlin examples for configuring tasks are labeled backwards, the one labeled kotlin is groovy and vice versa.

Also for the kotlin example (incorrectly labeled as groovy) tasks.named is going to need a type parameter unless you are just using basic task properties like enabled.

Can you point which Kotlin example is labelled as Groovy? 🤔 By "configuring tasks" do you mean Customizing tasks, Custom tasks or Configuration?

Also for the kotlin example (incorrectly labeled as groovy) tasks.named is going to need a type parameter unless you are just using basic task properties like enabled.

I see 2 usages of named() and they are correctly labelled as Groovy. With Kotlin DSL you get computed extensions on tasks container, which you can call as tasks.taskName {}, which then expose typed accessor 👀

Can you share which Kotlin DSL examples don't work for you?

I was referring to Customizing tasks. I could not get tasks.taskName { } to work and not sure how you could make that work in Kotlin. As far as groovy you don't need to use named, you can just do taskName { }. The use of named in the groovy example made me think that was actually Kotlin as that is what you often have to do with Kotlin.

Unfortunately, I was just trying to switch from our hand done ktlint invocation to one of the plugins, but I could not get any of them to filter worth a darn and could not exclude some generated and third party source code from being linted.

As far as groovy you don't need to use named, you can just do taskName { }

Actually, you shouldn't use taskName { } in Groovy as it configures the task eagerly and the lazy version with tasks.named('taskName') is the preferred way - docs. Kotlin DSL is smarter, and it calls named() under the hood, so you get build performance improvements without even knowing it.

I tried the tasks.lintKotlinMain { } (as shown in the documentation) on the test-project and all seems to be working as expected:
image

you can even see the extension implementation I was referring to:
image

You probably want to verify you configured Kotlin DSL correctly and if you're passing the right task name 👀
I'd even say in most cases you want to configure all tasks, not just one, running one a single soruceSet, so I'd guess that what you're actually looking for is:

tasks.withType<LintTask>().configureEach {
    experimentalRules.set(true) // or any other config
}

tasks.withType<FormatTask>().configureEach {
    experimentalRules.set(true) // or any other config
}

Thanks for the answers @mateuszkwiecinski and hopefully that worked for you @dalewking

Regarding:

Unfortunately, I was just trying to switch from our hand done ktlint invocation to one of the plugins, but I could not get any of them to filter worth a darn and could not exclude some generated and third party source code from being linted.

There are some good notes on how to do that here.
Because our tasks inherit from SourceTask, excludes are based on package root. So if you need to go above the package root to customize source paths to exclude you need to edit the source of the task -- which it brings in from the matching Kotlin compile task for the particular sourceSet you are changing:

tasks.named("lintKotlinMain") {
    source = source - fileTree("$buildDir/generated")
}
tasks.named("formatKotlinMain") {
    source = source - fileTree("$buildDir/generated")
}

In fact, really ought to update our docs to include that note on additional exclude styles 🤔

Tested and determined readme has correct syntax here.

so, in order to make Jeremy's code work, I had to explicitly cast this to LintTask so it would pick up the source value (using Gradle 7.6.1) - not sure why I had to do that and he did not.

Oh, interesting. I thought I tested it, but feel free to issue a PR against the Readme if it needs a correction and you have the syntax working.

After reviewing @mateuszkwiecinski's post again, here's where I ended up:

   tasks.withType<LintTask> {
       this.source = this.source.minus(fileTree("src/generated")).asFileTree
   }

   tasks.withType<FormatTask> {
       this.source = this.source.minus(fileTree("src/generated")).asFileTree
   }

I had to do the final call to asFileTree because minus (or the operator) returns a FileCollection that has to be cast.