Question: why do I have to use `val shadowJar by tasks.getting(ShadowJar::class) { ... }` to exclude...

# gradle

[sdeleuze]

Question: why do I have to use val shadowJar by tasks.getting(ShadowJar::class) { ... } to exclude files with the shadow plugin instead of using shadow { ... } which provides a useless ShadowExtension lambda? Is the shadow plugin badly designed ? I see this kind of issue in various plugins so I would like to know what is the rationale behind this and understand that kind of issue and at what level this should be fixed ...

[eriwen]

Is the issue here that val shadowJar by tasks.getting(ShadowJar::class) is not intuitive? Jonathan has suggested an alternative that should work well.

That said, I’m sure John Engelman has a good reason for having folks configure ShadowJar tasks instead of using an extension.

[Czar]

do note, that code suggested by Jonathan will configure all tasks of that type, while val shadowJar by... approach will only configure task named "shadowJar". This may matter in multi-module projects.

[Czar]

my 2 cents:

tasks {
    val shadowJar: ShadowJar by getting
    shadowJar {
        // your config
    }
}

Or if you do not want to have tasks {} block:

val shadowJar: ShadowJar by tasks.getting {
    // your config
}

[sdeleuze]

Thanks for your feedback. Could that make sense I suggest to the plugin author to add more configuration options to the extensions in order to have a useful shadow { ... } like in Groovy ?

[sdeleuze]

I mean users just want to get something uesful by default, and shadow { .. } is what they are going to use.

[sdeleuze]

Do you provide guidelines for Gradle plugin developers that make this kind of things clear ?

[gildor]

Because problem that you mentioned is typical for many plugins, but shadow plugin has reasonable defaults.

[gildor]

As I understand recommendation for plugin authors is to have good defaults and configurable defaults for tasks, si shadow extension wouldbe probably useful

[sdeleuze]

I would like to be able to do http://imperceptiblethoughts.com/shadow/#filtering_shadow_jar_contents by just writing shadowJar { } like in Groovy

[sdeleuze]

Is there something Shadow Gradle plugin can do about that ?

[sdeleuze]

Or do they have to copy these properties to the extension and get the tasks retrieve these properties ?

[sdeleuze]

Is it by design that extension get short access via lambda but not tasks ?

[gildor]

shadowJar on groovy is dynamic syntax you can do the same in Kotlin, but you don't have type safe context there, so it's mostly useless:
tasks {
"shadowJar" {
this::class == Task::class
}
}

[gildor]

You should specify task type to have type safe accessors

[gildor]

For extensions Kotlin dsl generates type safe accessors, I remember that guys form Gradle mentioned that they probably will implement also for non-dynamic tasks to have type safe accessors for them too, but for now you should specify type manually using by getting or using reified generic syntax

[gildor]

Or, as alternative solution, ask plugin authors to use plugin extensions instead of direct task configuration, because most of use cases can be solved using rational defaults and extensions, without direct task configuration (if you enough default task and you don't want to create more using plugin default task as parent implementation)

[gildor]

Or do they have to copy these properties to the extension and get the tasks retrieve these properties ?

Yes, this is possible, you can use extensions config as default values for task config. As I remember the latest versions of Gradle even have some API to reduce boilerplate in this case

[sdeleuze]

Ok thanks