Hacker News new | past | comments | ask | show | jobs | submit login

This may partly be Stockholm syndrome, but I'm actually somewhat fond of Gradle (a Groovy DSL for configuring builds/managing dependencies for Java projects). It's certainly not perfect and I think it would be overkill for simple builds, but I find the DSL well suited to writing custom build tasks.

As an example, I wrote a Gradle plugin for a project I work on that lets you write:

  apply plugin: 'mycompany.service'
  
  mainClassName = 'mycompany.Main'
  service {
    id = 'serviceid'
    port = 1234
  }
This results in a `buildImage` task being added which builds a Docker image that runs `mycompany.Main` and exposes the specified port (and does some Docker tagging with the service id).

Implementing this plugin was straightforward, less than 50 lines of Groovy, most of which is invoking another DSL[1] for creating a Dockerfile.

[1] https://github.com/bmuschko/gradle-docker-plugin#creating-a-...




> Gradle (a Groovy DSL

Gradle is not a Groovy DSL. Gradle enables you to write its build files in either Kotlin or Apache Groovy, and perhaps there'll be more choices later on.

> Implementing this plugin was straightforward, less than 50 lines of Groovy

Did you know Gradleware now recommend using Kotlin for writing plugins for Gradle versions 3.0 and later?


Gradle may not claim to be a "Groovy DSL" anymore, but they certainly used to.

From the overview page at the time of the 1.0 release

At the heart of Gradle lies a rich extensible Domain Specific Language (DSL) based on Groovy. https://web.archive.org/web/20120724040152/http://www.gradle...

Now they just call it a "DSL" but also say that a build script is also a Groovy script https://docs.gradle.org/4.0/dsl/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: