On joining Gradle

A new year brings new opportunities, and in my case a new job The Gradle build tool has been an integral part of my developer career (both closed and open source) as you may have guessed by the content found in this blog. I’ve been an avid user of Gradle since the early days (my first build was made with Gradle 0.4) which means I’ve seen the tool grow to its current state as an outsider, I’m delighted and excited to helping steer its growth from the inside. I look forward to continue engaging the broad Gradle community and beyond. Read More


Gaining insight into a Gradle build

Every Gradle build has access to a default set of tasks that can deliver insight information on your build settings. You probably have come across the dependencies task. This task can display dependencies associated with all configurations of a particular project; you can even instruct which configuration to be queried if the list of configurations happens to be very long. Let’s say we have a Java project that looks like this build.gradle plugins { id ‘java’ id ‘org.kordamp.gradle.project’ version ‘0.11.0’ } ext.build_property = ‘build’ config { license { enabled = false } publishing { enabled = false } } repositories Read More


5 Gradle plugins for working with modular Java projects

Java 9 was release in September 2017 and with it came a brand new modular platform known as JPMS, delivered by Project Jigsaw. Building projects that an leverage this new feature can be a bit daunting however the Gradle plugins in the following list can help you in keeping things under control. 1. JDeps – https://github.com/aalmiray/jdeps-gradle-plugin This plugin generates a report of your production code and compile/runtime dependencies using the jdeps tool available since Java 8. Jdeps can tell you if your codebase is vulnerable to API changes such as relying on internal APIs (like sun.misc.Unsafe) even if you don’t Read More


The Gradle SuperPOM

Following up with the Gradle POM, where a familiar structure found in Maven projects can be brought to Gradle projects, I’d like to discuss another Maven feature that many see as an advantage and that’s lacking in Gradle: the ability to enforce settings in a top-down fashion with hierarchical POM files. In Maven, a parent POM delivers configuration that will be used by a child POM as is. Children POMs have the option to override and extend these properties. A typical use case in parent POMs is to provide <pluginManagement> and <dependencyManagement> sections; they also configure default dependencies, properties, plugins, Read More


The Gradle POM

Gradle is an extensible and very flexible build tool capable of building projects that target many platforms, not just Java. In the Java space it’s often compared to Apache Maven; one of the often cited complains against Gradle is that it’s “too complicated” or rather “too flexible” when compared to Apache Maven. It appears a large percentage of Maven users do love having a fixed structure that restricts the amount of havoc a junior developer may bring to the project if he or she desires to play with the build file. However this fixed structure also restricts power users from Read More


An opinionated way to build Gradle projects

If given a choice I’d pick Gradle over Maven as build tool 9 times out of 10. Gradle is a very extensible tool which has allowed me to customize my builds exactly how I want them to be, however this flexibility comes at a price as there’s a lot of configuration that has to applied to make a project follow a certain structure. Let’s say you’ve created a project and release it as Open Source. You’d typically post a release to Maven Central which requires following these guidelines, which include A well defined POM file. Attach a sources JAR. Attach Read More


Nested Composite Builds with Gradle

If you work with source code of multiple dependencies at the same time then Composite Builds is the feature you didn’t know you needed. Back in October 2016 Gradle 3.1 introduced Composite Builds to the world. The idea behind this feature is to let a project build its external dependencies as needed; think of quick fixing a bug or checking for breakages before publishing a snapshot release. I’ve got a real world scenario for this feature: the set of builds for JSR377, the Desktop Application JSR. This specification provides the following artefacts jsr377-api: Defines the API for this JSR. jsr377-spec: Read More


Multi-module project builds with Maven and Gradle

Just came back from wonderful JCrete® 2018. This year didn’t disappoint, we had close to 110 people openly sharing ideas and knowledge on both technical and soft skills matters. Here’s a picture of the final schedule, captured by fellow Java Champion Badr Elhouari: If you are wondering what was the schedule of @JCreteUnconf 2018! Really 💜 my first #JCrete & #Unconference experience 🤩 brilliant people with top notch content. Thanks a lot for all the disorganizers @heinzkabutz @javaperftuning @rgransberger @aalmiray @IXSC & others 👍💪👌 pic.twitter.com/iHk0dxSqle — Badr Elhouari (@badrelhouari) July 26, 2018 Every single one of those notes represents a Read More


Customize JAR manifest entries with Maven/Gradle

How many times have you found yourself in a situation where you can’t tell if the artifacts used by the application are the correct ones or not? How many times have you looked at a bug report stating that the problem is caused by version X of a particular artifact but you are certain the bug was fixed in said release? On closer inspection (after unpacking, debugging, even decompiling!) you find that the artifact in production is not the right one even though the version appears to be the correct one. One option we have to mitigate this problem is Read More


Maven scopes vs. Gradle configurations

Both Maven and Gradle are popular choices when it comes to building Java projects. These tools share common traits but there are some key differences that make you more productive depending on a particular scenario (no, I’m not referring to the XML DSL vs. Groovy/Kotlin DSL schism), case in point scopes vs. configurations. Scopes and configurations are used by each tool to define dependencies and how they affect different classpaths, such as the compilation and runtime classpaths. Maven defines 6 scopes: compile, runtime, provided, system, test, and import. Gradle on the other hand defines the following configurations when the Java Read More


ˆ Back To Top