Hacker News Reader

Comment by invalidname | Hacker News Reader

How is it different from: https://rife2.com/bld

> bld was created because we're not really interested in build tools. We use them because we have to, but we'd rather just get on with coding the real stuff.

no interest in build tools, so let's create our own. Baffling.

Never heard of bld before, but my read is that they were overwhelmed by the complexity of existing tools, and wanted one with minimal frills that doesn't get in the way and which looks like app code (as opposed to using a declarative language), so they wrote one. I suppose they wanted to "get it over with"... whether this is a pipe dream or not remains to be seen ;)

Build tools are complex because builds are complex. Of course, if you create a bespoke tool for your specific use case and then a bunch of other people use it but it doesn't really gain widespread adoption, you can keep stuff simple.

I'm not saying that there's not accidental complexity in current build tools and that a new build tool couldn't strike the balance better, but a rarely used build tool being simple doesn't really say much (and this much is true for almost any kind of software).

I'm not disputing anything you say, but my comment was aimed at explaining why someone who doesn't like dealing with build tools would want to write one.

I don't want to have to defend their choice or explain why build tools are often complex and cumbersome.

Sadly there's tons of code-based Java build tools, but possibly zero concise (toml/yaml- like) declarative build tools. If you're currently using Groovy or Kotlin scripts for building Java projects however, then Java build scripts are appealing.

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()
        }
    }

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

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.

Its not really different. Except that bld seems to only support Java 17+, whereass 1JPM support Java 8+ and there is still a lot of Java 8 projects out there I guess.

Another difference is also that 1JPM is a single file, which has its advantages and disantwages, checkout the README for more details.

You don't need to install anything. Just include the Java file in your repository.

"Install bld through Homebrew, SDKMAN!, JBang, ..."

Those are just alternatives.

Literally the first option they list is to just download the jar and run it manually, because this tool truly doesn't need any installation.

I haven't been in the java ecosystem in a while, but when I was using Maven you could just download the portable version and run it, and towards the tail end you could just include a simple mvn build shim that would pull down the correct version of maven and run it in a portable way (I think this was an idea borrowed from Gradle).

Maven itself, afterall, was nothing more than a java application (as was Ant before it).

Reply on news.ycombinator.com