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

Documentation wrong on customizing tasks #251

Closed
dalewking opened this issue May 2, 2022 · 9 comments
Closed

Documentation wrong on customizing tasks #251

dalewking opened this issue May 2, 2022 · 9 comments

Comments

@dalewking
Copy link

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.

@mateuszkwiecinski
Copy link
Contributor

mateuszkwiecinski commented May 3, 2022

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?

@dalewking
Copy link
Author

dalewking commented May 3, 2022

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.

@mateuszkwiecinski
Copy link
Contributor

mateuszkwiecinski commented May 4, 2022

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
}

@jeremymailen
Copy link
Owner

jeremymailen commented May 6, 2022

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
Copy link
Owner

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

@jeremymailen
Copy link
Owner

Tested and determined readme has correct syntax here.

@jasonab
Copy link
Contributor

jasonab commented May 31, 2023

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.

@jeremymailen
Copy link
Owner

jeremymailen commented Jun 4, 2023

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.

@jasonab
Copy link
Contributor

jasonab commented Jun 5, 2023

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.

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

No branches or pull requests

4 participants