sdeleuze
05/25/2018, 10:46 AMval 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
05/25/2018, 3:42 PMval 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
05/25/2018, 3:49 PMval shadowJar by...
approach will only configure task named "shadowJar". This may matter in multi-module projects.Czar
05/25/2018, 3:50 PMtasks {
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
05/28/2018, 11:56 AMshadow { ... }
like in Groovy ?sdeleuze
05/28/2018, 11:57 AMshadow { .. }
is what they are going to use.sdeleuze
05/28/2018, 11:57 AMgildor
05/31/2018, 11:22 AMgildor
05/31/2018, 11:24 AMsdeleuze
05/31/2018, 12:39 PMshadowJar { }
like in Groovysdeleuze
05/31/2018, 12:39 PMsdeleuze
05/31/2018, 12:40 PMsdeleuze
05/31/2018, 12:40 PMgildor
05/31/2018, 1:52 PMgildor
05/31/2018, 1:53 PMgildor
05/31/2018, 1:55 PMgildor
05/31/2018, 1:57 PMgildor
05/31/2018, 2:01 PMOr 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
05/31/2018, 2:37 PM