Break New Ground

Migrating a Helidon SE application to Gradle

Helidon 2.0 was recently released and with it came a host of new features and capabilities. Please refer to the docs & guides to know more about these features. Today I'd like to showcase how to build, test, and package a Helidon SE application using the Gradle build tool.

Unlike Apache Maven, Gradle does not provide a mechanism similar to Maven archetypes to bootstrap projects. There's nothing stopping us from creating a Helidon SE project from scratch, however we can also leverage a project created using the Helidon SE Maven archetype, and that's exactly what we'll do as suggested in the Helidon SE Quickstart guide.

Now, there are various ways for structuring a Gradle build depending on your own preferences and the version of Gradle you may be using. This post assumes the lower Gradle major version to be 6, the setup was verified with 6.5.1 as a matter of fact. You may be familiar with the build.gradle file, as of Gradle 6 the settings.gradle must be present as well. Project properties may be defined in a gradle.properties files, similar to Apache Ant's build.properties. My personal preference is to keep project properties (static, conventional, dynamic) in gradle.properties, plugin definitions in settings.gradle, and build instructions in build.gradle, thus the build files look like the following

As you can appreciate there are 3 plugins applied to this build

  • com.github.johnrengelman.shadow takes care of repackaging dependencies and production code into a single, executable JAR.
  • java defines this project as a Java project.
  • application marks this project as an application. Allows launching and packaging the application.

With these settings in place we can now build, test, and execute the application using the Gradle build tool. The application plugin adds a couple of tasks that can be used to run the application as well as package it as a standalone distribution, complete with a launch script. You can run the application directly from the build by invoking the run task as shown next.

You may also package the application as a distribution; this distribution can be created by invoking the distZip goal.

All required JAR files plus a couple of launch scripts are contained in said distribution.

Finally, the shadow plugin lets you repackage the application in such a way that all classes and resources (including those from 3rd party dependencies) are found in a single JAR (usually nicknamed fatjar or uberjar) which also happens to be an executable JAR. Creating this JAR can be done by invoking shadowJar; alternatively you may invoke runShadow to check that the application works as expected when repackaged as a single JAR.

And there you have it, migrating a Helidon SE project from Apache Maven to Gradle is not that difficult. I'll use this configuration as the basis for other posts showing how to configure and package Helidon SE applications with jlink and Graal Native Image.

Image by S. Hermann & F. Richter

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.