Repeatability of the Build

Apache Ant was a task-oriented build tool which was widely used in Java application builds. for those who remember it. Task-oriented.

What Maven brought was an opinionated approach to the build.  No more tasks; goals.  Yes, there are options, but they all focus on the goal at hand.  The process and sequence and the produced artifacts will be mostly predetermined.

There will always be developers who will build their own Java servlet implementations and there are admins who want procedural and exact control over the build process.  For this lot, Ant was ditched in favour of Gradle.  Gradle was Tasks-plus.  Flexibility in control of the flow, no opinions and the power of Java plugsin.  Maven to Gradle was a background task on many architects' radar.

Like all custom procedures, repeating a Gradle build after a few months or even years turned out to be a R&D exercise of its own.  Yes, Gradle had performance benefits, and standard plugins, but the repeatibilty of the build continued to hinder wider adoption.

Continuous Integration and Continuous Development (CI/CD), and to some extent the Cloud and the DevOps revolution (yes, I will call it that), the focus was back on the app, with cute build shortcuts and innovations seen as dimly as OS tweaks.  Build failure better be a code issue than a build issue!

And as we see, Maven is in favour again.  The build must be repeatable, on demand, and even months or years into the future.

This tribute to Maven (so far!) will not be complete without its foundational tool: the artifact repository.  Programming languages and build systems have adopted the approach of Maven Central, which started with a single computer.  Docker image repositories and NPM repositories continue this approach that was innovative in the pre-Cloud days.

For those versed in the JS ecosystem, the argument about the repeatability of the build continues in the Yarn vs NPM debates.