kotlinter-gradle icon indicating copy to clipboard operation
kotlinter-gradle copied to clipboard

Documentation wrong on customizing tasks

Open dalewking opened this issue 3 years ago • 5 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.

dalewking avatar May 02 '22 22:05 dalewking

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?

mateuszkwiecinski avatar May 03 '22 06:05 mateuszkwiecinski

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.

dalewking avatar May 03 '22 22:05 dalewking

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
}

mateuszkwiecinski avatar May 04 '22 04:05 mateuszkwiecinski

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")
}

jeremymailen avatar May 06 '22 05:05 jeremymailen

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

jeremymailen avatar May 06 '22 05:05 jeremymailen

Tested and determined readme has correct syntax here.

jeremymailen avatar Mar 14 '23 16:03 jeremymailen

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.

jasonab avatar May 31 '23 21:05 jasonab

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.

jeremymailen avatar Jun 04 '23 04:06 jeremymailen

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.

jasonab avatar Jun 05 '23 19:06 jasonab