Question why do I have to use `val shadowJar by tasks gettin

Question

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

jlleitschuh · Answer

The `extension` is usually considered the wa that you configure the entire plugin The configuration that you put on the `extension` can cause the plugin to create various different tasks that are outside the scope of what any normal user would need to configure Additionally things configured on an extension might do things like cause multiple tasks to be created depending upon how it s configured The configuration of the tasks with code like ``` tasks withType lt ShadowJar gt Some config here ``` It s more about configuring the logic specific to one part of a plugin s task execution < eriwen> any interest in chiming in here to add any additional information and or a link to a Gradle doc that explains the differences better than I can

eriwen · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

I mean users just want to get something uesful by default and `shadow ` is what they are going to use

sdeleuze · Answer

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

sdeleuze · Answer

Any chance to have a feedback about what shadow plugin should do to improve compat with the Kotlin DSL see my comments above

gildor · Answer

< sdeleuze> what is your typical config for shadowJar

gildor · Answer

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

gildor · Answer

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

sdeleuze · Answer

I would like to be able to do <http imperceptiblethoughts com shadow filtering shadow jar contents> by just writing `shadowJar ` like in Groovy

sdeleuze · Answer

Is there something Shadow Gradle plugin can do about that

sdeleuze · Answer

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

sdeleuze · Answer

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

gildor · Answer

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 · Answer

You should specify task type to have type safe accessors

gildor · Answer

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 · Answer

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 · Answer

gt 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 · Answer

Ok thanks