Hacker News Reader

Comment by Tainnor | Hacker News Reader

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).

View on HN

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.

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.

Reply on news.ycombinator.com