https://gradle.com/ logo
Join Slack
Powered by
Is there a convention/naming guide for task names?...
# plugin-development
m
Is there a convention/naming guide for task names? Should I start with a verb? Put the plugin name as a prefix? Something else? Also same thing for configurations?
t
Generally, task names are verbs at the imperative form, but of course there are exceptions (
classes
, 
jar
, 
javadoc
for the Java plugin: https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_tasks). Gradle tends to use verbsource setnoun but thirdparty plugins prefer pluginverb (e.g. spotlessApply) Configurations are generally nouns.
👍 1
(using the plugin name as a prefix is likely copied over from Maven)
v
That's a highly subjective question. :-D I usually orient at what the built-in plugins do.
Unfortunately, even those are not fully consistent
👆 1
t
👀 1
v
But yeah, usually more something like verbContextSubject like compileTestJava, so the Gradle invocation is like you telling it what to do
m
That’s a highly subjective question.
Yea, agreed but also wished there was some guidance for unopinionated persons.
I usually orient at what the built-in plugins do.
Makes sense and the 
getTaskName
is interesting there but also I kind of like having the plugin name in the task. Makes it easy to look up the task like 
spotlessApply
, etc...
Configuration are becoming somewhat problematic too. A modest KMP project can have dozens of them. Nameclashes appart, it’s hard to tell what each one is for
v
Yeah, but that is more a topic for documentation probably. If you have meaningful enough names, they will become too long. 😄 Besides that KGP anyway registers configurations it should not register like 
...DependencySources
configurations which get removed again in 2.0.10.
Would maybe be nice if a configuration could have a description that then makes it into the doc of the generated accessor, so that at least from Kotlin DSL you can then see what it is for easily.
💯 1
p
Ideally, it would be unique and enforced by Gradle based on plugin id, because there is also no option as a user to resolve a clash
💯 1
m
That would be the dream (also for output dirs/files!)
a
It'd help if the description of things was more visible https://github.com/gradle/gradle/issues/25148
⭐ 1
👌 1
Also if internal tasks/configs could be hidden. Sometimes I add a character that isn't a valid Kotlin name character, so that Gradle doesn't generate a Kotlin DSL accessor. That kinda helps keep build scripts more tidy.
Copy code
tasks.register("pluginTask~internal")
❤️ 1
m
I find this both beautiful and scary at the same time 😄
v
Imho just makes using them more cumbersome when necessary. 🤷‍♂️ 🙂
10 Views
Open in Slack
PreviousNext
Powered by