Hi im having issue differentiate gradle tasks vs gradle plugins ? What are the benefit of using this...

# gradle

[Markus Fung]

Hi im having issue differentiate gradle tasks vs gradle plugins ? What are the benefit of using this instead of that ? An in which usecase it would be applied ?

[PoisonedYouth]

https://docs.gradle.org/current/userguide/plugins.html

[Markus Fung]

@PoisonedYouth Thanks but will there be any drawbacks in using plugin ? like build time ? dependencies ?

[Adam S]

hey @Markus Fung, can you say a bit more about what you’d like to figure out? Do you have an existing Gradle project that you’re trying to understand, or do you want to use Gradle in a new project? Are you familiar with any other build tools, like Maven, Make, or Ant?

[Markus Fung]

Im developing a custom gradle plugin to do the automation task ( fetch from an API to get a string resource ). But i wonder should i've done it with registering a simple task or not

[Markus Fung]

i dont really know whether it has performance impact or not on the build

[Markus Fung]

@Adam S

[Adam S]

ahh okay. So you want to know whether you should fetch the data within a task’s action, or in the plugin configuration?

[Markus Fung]

yes

[Adam S]

it’s best to use a task to do any sort of work, like fetching data from an API.

[Adam S]

Gradle has 3 phases https://docs.gradle.org/current/userguide/build_lifecycle.html

Whenever you run a task, Gradle runs through the phases - and tries to minimise the amount of work in each

1. Gradle discovers what projects are available, and where they’re defined
2. Gradle figures out what tasks it needs to run, and configures them
3. Gradle runs the tasks

[Adam S]

if you download the file within the plugin, and not in a task, then it will do this in phase 2 (Configuration). Plugins are always configured (because they can configure any task). Doing work in the Configuration phase is usually bad, because what happens if the user is running another task? Your plugin would download the file, even if it’s not necessary.

[Adam S]

doing work within a task is also really good because Gradle can cache the result https://docs.gradle.org/current/userguide/incremental_build.html, so if your task downloads the file once, then Gradle will keep track of the files it downloads and won’t download it again - unless it needs to

[Markus Fung]

thanks for your answer but im still not fully clear about it.

[Markus Fung]

im following this repo (https://github.com/cortinico/kotlin-gradle-plugin-template) for creating a plugin

[Adam S]

thanks for your answer but im still not fully clear about it.

that makes sense, Gradle is really confusing :) Keep asking questions!

[Markus Fung]

so in short, it creates a TemplateExampleTask

[Markus Fung]

this task only run when we explicitly running it, right ?

[Markus Fung]

so what is the different if i just create this task with

tasks.register("TemplateExampleTask") {
// do something
}

[Adam S]

tasks.register("TemplateExampleTask")

will create a task with the name of TemplateExampleTask, but the type won’t have a type of class TemplateExampleTask

To register a task with the type TemplateExampleTask, you need to specify the task

import com.ncorti.kotlin.gradle.template.plugin.TemplateExampleTask

tasks.register<TemplateExampleTask>("TemplateExampleTask")

(btw, it’s usually good to use tasks.register 👍)

[Adam S]

just to give an example about those 3 phases I mentioned earlier, try using println() to see what happens:

tasks.register("myPhaseExampleTask") {
  println("this will be printed in phase 2, the configuration phase")
  doLast {
    println("this will be printed in phase 3, the execution phase")
  }
}

if you run ./gradlew myPhaseExampleTask then you’ll see both lines printed.

But if you run a different task, like ./gradlew help, then you’ll only see the phase 2 line printed - because the myPhaseExampleTask task isn’t executed

[Markus Fung]

oh thankss, i learnt a new thing

[Markus Fung]

so

[Markus Fung]

if im targeting a plugin for Android, and i need to access the build variant.

[Markus Fung]

i should make a plugin to access the configuration phase ?

[Adam S]

I’m not very familiar with the Android Gradle Plugin, but I’ve done a little bit. Accessing data can be very difficult 😬 , so I won’t be much help

[Adam S]

it also depends on which AGP version you want to access? They introduced a new DSL in AGP 8

[Markus Fung]

oh yes

[Markus Fung]

so let me ask another question

[Adam S]

Gradle has the ‘Provider API’ which is used to avoid work in the configuration phase https://docs.gradle.org/current/userguide/lazy_configuration.html

[Markus Fung]

defining a task like this

tasks.register<TemplateExampleTask>("TemplateExampleTask")

and defining it in a plugin and then apply the plugin

[Markus Fung]

what is the benefit and drawbacks for each cases ?

[Adam S]

so in theory you can use a Provider to lazily access the build variant, and pass it into a task as a task input - then Gradle will be able to avoid doing work in the configuration phase.

[Adam S]

benefits of registering a task? That’s hard to list exhaustively, because it should be the only way to do it! (Even though Gradle gives 10 other different confusing ways to add tasks 🙄). But in general:

• lazy configuration = faster projects. Gradle will be able to skip work. Projects will load and run faster.
• better synergy with other plugins that use lazy config / Provider API
• generally easier to work with
• generally more compatible with Configuration Cache and Build Cache
cons:

• generally, learning Gradle is hard and confusing. There are a million different ways to hack a plugin together, and there are tonnes of outdated or bad-practice StackOverflow answers that are very confusing. You really have to get a good intuition of Gradle best practices, and learn to avoid the hacks and workarounds, or at least learn to contain them!
• some other Gradle plugins might not follow Gradle best practices, so integrating with them is more difficult

[Markus Fung]

so will there be overhead cost if im using plugin ?

[Markus Fung]

says i have a fetch api task

[Markus Fung]

by creating a plugin and registering a task inside it. I can still specify the fetch in doLast

[Markus Fung]

but with a plugin i can easily apply it to other module

[Markus Fung]

if it was a task in the build.gradle.kts script then i have to copy it to every module

[Markus Fung]

is it right ? (im defining the plugin in buildSrc)

[Adam S]

there will be some cost associated with creating and applying a plugin, but very minimal. The cost of copy & pasting a task in each subproject will be much higher!

[Adam S]

you can use a Gradle Build Scan (for free) to get a lot of details about what parts of a build are slow and fast https://scans.gradle.com/

[Markus Fung]

oh great

[Markus Fung]

thanks for the instruction

[Adam S]

I never focus on trying to improve performance unless I have to. I always try and sensibly reduce complexity and repetition. So long as you use the Provider API, Build Cache, Configuration cache, then make as many buildSrc convention plugins as you like!

[Markus Fung]

Yes, that's a really good mindset

[Markus Fung]

thanks for the discussion and sharing

[Adam S]

my pleasure!

[Adam S]

if you have any more questions then fire away, or you can ask in the Gradle Slack too (the link is in the channel description)

[Markus Fung]

Ah yes, thank you. You dont mind if i ask you again ? 😜

[Adam S]

nope!

[Markus Fung]

@Adam S do you know what this plugin do ?
kotlin-dsl-precompiled-script-plugins

[Adam S]

that’s part of the Kotlin DSL plugin https://docs.gradle.org/current/userguide/kotlin_dsl.html#sec:kotlin-dsl_plugin

You shouldn’t need to use it directly. Often Gradle plugins will be split up into multiple, smaller plugins, and the ‘main’ plugin will apply each of the smaller plugins. This just helps with organisation.

[Markus Fung]

so by applying kotlin-dsl , it already included kotlin-dsl-precompiled-script-plugins ?

[Adam S]

exactly

[Markus Fung]

haha that's really confusing reading these articles
https://proandroiddev.com/sharing-build-logic-with-kotlin-dsl-203274f73013

[Markus Fung]

why are they specifying it twice

[Adam S]

https://github.com/gradle/gradle/blob/v8.2.1/subprojects/kotlin-dsl-plugins/src/main/kotlin/org/gradle/kotlin/dsl/plugins/dsl/KotlinDslPlugin.kt#L29-L33

The kotlin-dsl plugin.

• Applies the java-gradle-plugin plugin

• Applies the kotlin-dsl.base plugin

• Applies the kotlin-dsl.precompiled-script-plugins plugin

[Markus Fung]

that's why my build still works even though i remove that kotlin-dsl-precompiled-script-plugins

[Adam S]

yeah, the internet is full of weird Gradle instructions. It’s really hard to tell if they’re applying a hack to fix a Gradle issue that doesn’t exist any more, or they made a mistake 🤷‍♀️

[Markus Fung]

yeah thanks a lot, without your guidance i wouldnt figure it out

[Adam S]

no problem :)

[Vampire]

if you have any more questions then fire away, or you can ask in the Gradle Slack too (the link is in the channel description)

The "or you can" should actually be "but you should" and "too" removed.
This thread is off-topic, as this channel is only for Kotlin-specific Gradle question like using Kotlin in Gradle build scripts or using the Kotlin Gradle Plugin, not for general Gradle questions. 😉

Also, speaking about idiomaticness, tasks are the "work doers" but should not have opinion to increase reuse. Same for extensions. Plugins then add opinon by adding extensions, registering tasks, wiring extension properties and task properties together and setting default values.