Release 0.1 Announcement

If you are like me, building native software has always painful regardless of the build system being used. Eight years ago, I showed that it doesn’t have to be that way, and Gradle has the potential of being a game-changer in that ecosystem. The JNI libraries are often the first encounter with native development for Java developers. This encounter isn’t always pleasant. As a first step in the ongoing native support in Gradle, I’m proud to announce the release of the JNI Library Plugin. It allows the users to build the JVM and native code side-by-side within the same project. It also support migration use cases where each components of the JNI library are built individually.

Everything you would expect from a JVM library is supported: publishing, testing, and developing within an IDE using the IntelliJ native importer or Eclipse Buildship.

The documentation is probably more important than the plugins themselves. For this reason, I spent quite a bit of time ensuring it’s of high quality. I was attached to rolling out quality samples first. They are goal-oriented, easy to write, and provide immediate value to you, the users. As Gradle is a very sophisticated build system, I’m often resorting to Sample Driven Development (SDD) before modelling or writing feature code. For this reason, everyone should feel free to open issues for use cases that are important to you but aren’t obvious to solve.

As for the user manual, the focus was on getting the core concept and direction of the plugins across. I suggest reading the terminology chapter to get a good understanding of the core concept. The JNI Library Plugin reference chapter is also a good place to start to learn about highlighted plugin of this release.

More will be coming in the future release.

The infrastructure is the invisible syndicate that ensure the users are always presented with quality work. One of the perks of working within the Gradle codebase was all the infrastructure already available. Sadly, lots of it is couple to Gradle, which prevents you from sharing the pain plugin authors are going through when developing high-quality plugins. Some of my supporting infrastructures are shared over on Gradle Plugin Development repositories. The goal is to fill the repository with all the tools plugin authors may require to be successful at his job. It includes fixtures for executing Gradle (i.e. using the TestKit Runner or the Gradle Wrapper), making sense of the Gradle output (i.e. comparing two builds, asserting execution events) and composing source samples for testing. You can look at Nokee’s repository for all the creative ways I’m using those fixtures for assembling the sample templates and automating the sample tests to name a few.

The infrastructure also support nightly release of the work in progress. The testing coverage is also an essential part of the infrastructure puzzle. I’m committed to providing high-quality plugins to Gradle users. As the great Titus Winter once said: if you like a feature, you should put a test on it. It is also known as The Beyoncé Rule.

It’s always hard to identify a clear roadmap as the software domain is forever changing. Despite this, I feel confident about the steps that will lead to version 1.0. I’m committed to providing high-quality plugins, which assume requires good test coverage. The features of this release are already providing a lot of values to the users. However, the test coverage for individual platforms is lacking. It’s a typical chicken and egg problem. Until version 1.0, I will split the R&D time between improving test coverage and adding valuable features for the users. Because of this decision, the 0.x versions may be a bit bumpy as the test coverage improve to lock the features in place and avoid bugs on a different platform. If you discover any issues with the plugins, please open an issue. I will make sure to prioritize a fix for those issues quickly for easy adoption.

So what does this all mean? It means there will be a heavy focus on adding test agents that support various toolchains, operating systems, and architecture. As the coverage improves, I will keep everyone informed via the blog and Twitter. Feel free to follow the most convenient, so you don’t miss any announcement.

Lastly, I want to take a moment to thanks everyone who took the time to fill the iOS development poll. If you haven’t filled it, you can still do so. The next phase of the native development by the Nokee team will focus on cross-compilation for iOS inside Gradle.