In this article, let’s revisit the topic of deploying Java apps on Cloud Run. In particular, I’ll deploy a Micronaut app, written with Java 17, and built with Gradle.

With a custom Dockerfile

On Cloud Run, you deploy containerised applications, so you have to decide the way you want to build a container for your application. In a previous article, I showed an example of using your own Dockerfile, which would look as follows with an OpenJDK 17, and enabling preview features of the language:

Requirements:

• an existing Google Cloud Platform account and project
• a Java or alternative language web application
• a Gradle build that creates a standalone executable JAR file

In youd build.gradle file, add the App Engine gradle plugin to your buildscript dependencies:

buildscript {
    repositories {
        jcenter()
        mavenCentral()
    }
    dependencies {
        classpath 'com.google.cloud.tools:appengine-gradle-plugin:2.+'
    }
}

Apply the plugin, to make use of it:

apply plugin: "com.google.cloud.tools.appengine-appyaml"

Then you can configure the appengine task to point at the standalone executable JAR:

What can you learn from millions of (Groovy) source files stored on Github? In this presentation, I analized source files in the Github archives stored on BigQuery, and in particular Groovy source file, but also Gradle build files, or Grails controllers and services.

What kind of questions can we answer

• How many Groovy files are there on Github?
• What are the most popular Groovy file names?
• How many lines of Groovy source code are there?
• What’s the distribution of size of source files?
• What are the most frequent imported packages?
• What are the most popular Groovy APIs used?
• What are the most used AST transformations?
• Do people use import aliases much?
• Did developers adopt traits?

For Gradle, here are the questions that I answered:

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.

While at the Groovy/Grails eXchange conference in London last month, I had the pleasure and honour to interview Hans Dockter, creator of Gradle and CEO of GradleWare. This interview was recorded and published by SkillsMatter.

Here’s a list of questions I had the chance to ask Hans:

• What’s Gradle?
• Any new about Gradle 1.0 and what’s being worked on?
• Why is Gradle using Groovy for its DSL?
• Is it possible to enforce conventions and standards à la Maven?
• Some words on IDE integration, roadmap, etc?

Check the video!

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.