20 April 2022
This development log (devlog) is more extensive than expected in the following entries. It includes most work done during February and March in no particular order.
Performance tests are essential for Nokee plugins to turn 1.0.
We focused on performance comparison and repeatable profiling.
We developed a new runner, similar to our Gradle runner, to perform build experiments.
At the moment, we are tracking the performance of a JNI library plugin implemented using the Software Model and our Nokee plugin as part of the
First-class support for building iOS applications and libraries requires a lot of upfront work. Instead, we can shortcut the work required by adapting the Xcode build system to Gradle and progress backward. We named this solution build adapters as it adapts a complete build system to Gradle, similar to an included build. We already have an experimental CMake build adapter that we can use to build Google Test as a source dependency. The goal of build adapters is to reduce the migration cost while maximizing maintenance and performance.
We developed most of the infrastructure for handling Xcode workspace and projects. Gradle/Nokee can build targets within a single Xcode project. We successfully validated this first step using the VLC iOS application as shown below:
The published build scan is available here.
The Universal Model (UM) is a data-oriented design to configure Gradle. The typical configuration model (often referred to as vanilla Gradle) lacks support for deeply nested domain objects. The Universal Model focuses on breaking the boundaries between Gradle containers allowing a universal space for all domain objects. The model follows a plain Entity-Component-System architecture with the ability to project Entity into vanilla domain objects. You can follow our technical rambling about the Universal Model in our PRs.
All of our platform plugins use the Universal Model, i.e.
The latest work focus on performance and clean architecture.
We identified hot spots that we will investigate before releasing v0.5.
We also untangled capabilities that should build on top of the Universal Model, i.e. classic
Action execution, component elements tracking (similar to Gradle’s domain object container), etc.
Finally, we prepare the architecture to support near-future capabilities such as reporting and custom repositories like Conan and vcpkg.
All of our documentation is statically compiled using JBake. Our needs and complexity far outweigh the official plugin’s capability, mainly around multi-repository cooperation. We wrote our plugin to better support our documentation development. This plugin will allow splitting documentation to accelerate its growth by improving test performance.
As part of our test fixtures and documentation samples, we have to maintain many Gradle build scripts. We often compose those scripts from multiple snippets. Gradle’s multi-DSL language support (Groovy/Kotlin) makes this task challenging. For this reason, we wrote a model over Gradle build script. This model is crucial for our upcoming documentation samples and user onboarding stories, e.g. build init templates.
The effortless nature of the build adapter plugins is a great way to bridge other build systems with Gradle. However, managing which Nokee distribution to use and aligning the versions between projects is tricky. We want Nokee to feel like a core Gradle plugin despite being a 3rd party plugin. We tried solving the issue via an init plugin. This solution had many moving pieces, making it inadequate for users. Instead, we experimented with a settings plugin that provides a much easier user interface.
The Gradle team provided us with a Gradle Enterprise instance for Nokee. Although we are Gradle experts, the onboarding helped us identify a few issues with our build. As part of this effort, we took the time to upgrade our Gradle version to 7.4. We also worked on our documentation pipeline, which had a lot of caching issues.