4 ms·

I mostly like the Kotlin flavor of Gradle, but it still has some relatively simple workflows for which you need to deeply understand the execution model of Grad

I mostly like the Kotlin flavor of Gradle, but it still has some relatively simple workflows for which you need to deeply understand the execution model of Gradle. The ideal build tool would just work intuitively - i.e. would be geared towards developers rather than build tool nerds. For example, I wanted a standalone database migration task that wouldn't be run by default. The magic for that is "doLast", which I don't think describes what it's actually doing particularly well. tasks.register("db-migrate", DatabaseSetup::class) { doLast { println("Now migrating") migrate() jooqGenerate() } }

Tainnor 2y ago
The thing about gradle is that you need to understand its model first (especially that you're describing build steps, not executing them directly). After you do that, it's not that hard anymore, but I agree that it would be better if it was slightly more intuitive. But then again, this is well explained in the docs, it's just that, sadly, today nobody has any time to read docs for the 5000 tools that we use anymore (which I can't fault individual engineers for).
- imtringued 2y ago
  His complaint is that it should have been something like "executeTask" or "doAction" or "lazyTask". Anything that implies something about the execution model of the task. Nobody really cares about the order of the actions within a single task most of the time.
  - NovaX 2y ago
    In the example the DatabaseSetup is an existing task type that is registered under a new name. Since that has an action body, the doFirst and doLast append logic to run around that. Thus, after setting up the database it then runs a migration and code generator phase. The more straightforward way is to define a new task and use a dependsOn relationship. val databaseSetup = tasks.register<DatabaseSetup>("databaseSetup") tasks.register<GenerateJooq>("generateJooq") { dependsOn(databaseSetup) } class GenerateJooq : DefaultTask() { @TaskAction fun run() { println("Now migrating") migrate() jooqGenerate() } } It is more code to define the custom task, but then allows for adding command-line input options. The doFirst / doLast are script shortcuts for quick proof-of-concept projects, whereas custom tasks are preferred for maintainability of long-lived ones.

Tainnor 2y ago

The thing about gradle is that you need to understand its model first (especially that you're describing build steps, not executing them directly). After you do that, it's not that hard anymore, but I agree that it would be better if it was slightly more intuitive. But then again, this is well explained in the docs, it's just that, sadly, today nobody has any time to read docs for the 5000 tools that we use anymore (which I can't fault individual engineers for).

imtringued 2y ago
His complaint is that it should have been something like "executeTask" or "doAction" or "lazyTask". Anything that implies something about the execution model of the task. Nobody really cares about the order of the actions within a single task most of the time.
- NovaX 2y ago
  In the example the DatabaseSetup is an existing task type that is registered under a new name. Since that has an action body, the doFirst and doLast append logic to run around that. Thus, after setting up the database it then runs a migration and code generator phase. The more straightforward way is to define a new task and use a dependsOn relationship. val databaseSetup = tasks.register<DatabaseSetup>("databaseSetup") tasks.register<GenerateJooq>("generateJooq") { dependsOn(databaseSetup) } class GenerateJooq : DefaultTask() { @TaskAction fun run() { println("Now migrating") migrate() jooqGenerate() } } It is more code to define the custom task, but then allows for adding command-line input options. The doFirst / doLast are script shortcuts for quick proof-of-concept projects, whereas custom tasks are preferred for maintainability of long-lived ones.