When developing new projects on my laptop, I often run some commands over and over again. Regardless of how far you’ve gone with your CI/CD pipelines, running commands locally without resorting to becoming a bash ninja can be pretty easy with… just!

just is a handy way to save and run project-specific commands

It’s a command-line tool that lets you define some commands to run (called recipes), in the form of a Makefile-inspired syntax. It even allows you to define dependencies between the various tasks of your justfile. It runs across all environments (Mac, Linux, Windows), and is quick to install. It loads .env files in which you can define variables specific to your project (other developers can have the same justfile but have variables specific for their projects)

Once in a while, when talking about Gradle with developers, at conferences or within the Groovy community (but with the wider Java community as well), I hear questions about Gradle. In particular Gradle vs Maven, or whether developers adopt the Kotlin DSL for Gradle builds.

In the past, I blogged several times about using BigQuery and the Github dataset to analyze open source projects hosted on Github, by running some SQL queries against that dataset. You might want to have a look at this past article on some Gradle analysis with BigQuery. Considering those questions popped up recently, I decided to do a quick run through those questions with some simple queries.

Gradle is becoming the build automation solution of choice among developers, in particular in the Java ecosystem. With the Github archive published as a Google BigQuery dataset, it’s possible to analyze those build files, and see if we can learn something interesting about them!

This week, I was at the G3 Summit conference, and presented about this topic: I covered the Apache Groovy language, as per my previous article, but I expanded my queries to also look at Grails applications, and Gradle build files. So let’s see what the dataset tells us about Gradle!

Since I started using Gradle for building my projects, as soon as I needed to create a brand new project from scratch, I wished that Gradle guided my hand and created the right directory structure and minimal Gradle build script.

A bit less than two years ago, I was inspired by Dierk’s gist providing a basic build that provided two tasks, one for creating the directory layout, and the other one to create the Gradle wrapper. I turned that gist into a blog post of my own, with just minor version updates, as I wanted to remember how to do that the next time I’d create a new Gradle-based project.

There are various options for building your Groovy projects: including Ant with the Groovyc Ant task, or with Gradle Groovy plugin. But today, I’d like to speak about Maven. You have actually two possible choices: GMaven or the Groovy Eclipse Maven plugin.

GMaven

GMaven 1.4 already allowed you to use Groovy 2.0 even before the final release of Groovy, although a new 1.5 version is about to be released soon, which should also include the option to use the “invoke dynamic” support which is currently missing for GMaven 1.4.

Dierk published a gist on GitHub with a handy Gradle build script to help you bootstrap a Gradle-built project from scratch, without having to create the directory layout manually, or install the Gradle wrapper.

This is pretty neat and should be integrated in Gradle to ease the creation of projects!

I’ve updated the gist with a more recent version of Groovy and Gradle.

And so that I never forget about this handy Gradle build script, I’m blogging about it and reproducing it here, to save me precious minutes finding it again the next time I need it! So without further ado, here’s the script in question:

The Gradle project is moving quickly towards its final version and we hear more and more projects adopting or migrating to Gradle for their build and project automation. Gradle founder Hans Dokter pushed very interesting posts those past days:

• On our way to Gradle 1.0: where he explains the current features being worked on before being able to reach 1.0, with a strong focus on three key aspects: the new dependency cache, the daemon, and performance improvements.
• In Welcome to the new Gradle dependency cache, Hans details the current critical issues that all other build systems face with the non-reproducability of their builds due to the poor design of the current dependency cache solutions, and then goes on to explain how Gradle’s new solution solves all these problems in an elegant way.

Last but not least, you should also check out the “week in Gradle” column, which will give you the latest news on everything Gradle every week, starting this week, covering the interesting project development, job offerings, appearance at conferences, tweets, articles, and more.

I’ve just come across a clone of Groovy’s AntBuilder. It’s being built with JRuby and allows you to write your build scripts in JRuby by reusing Ant’s tasks.

That was a pleasure to see Ruby inspired by our concept of builders, and now, they also copy our own builders. I’d simply say that imitation is the best form of flattery. Kudos guys!

I’m glad I just received my Maven Developer’s Notebook, from O’Reilly. My friend Vincent Massol and Tim O’Brien co-authored this great book on Maven, a definitely needed reading for all those who want to learn more about Maven, or who wants to get started quickly. I had the chance of being one of the reviewers and it allowed me to learn quite a few tricks in the process, at the same time I was converting one of my projects at work to a “mavenized” build process and integrating it inside Luntbuild for continuous integration. I particularly liked the “best practices” aspects both authors managed to give throughout the different labs. This book is a must read, go and get it at your nearest bookstore!

Recently, on Maven’s user list, someone wanted to be able to script Maven with Groovy, like it was already possible with BeanShell or Jython thanks to specific Jelly tags. But unfortunately, Maven didn’t provide that kind of support for Groovy.

But there are good news on that front since Jeremy Rayner contributed a nice Groovy Ant task.

That Ant task will be available in the upcoming Groovy release (jsr-02), so if you want to play with Maven and Groovy, you’ll have to build Groovy from sources in the meantime. But I’m going to reveal how to script Maven with Groovy in advance.