All versions since 1.0.0-beta-1

1.0.0-beta-1

Managing Jextract installations has moved to a shared build service. Running clean doesn’t destroy the downloads and installations anymore, because they are no build artefacts or task outputs. This reduces Jextract-related network requests.
Custom download locations for Jextract distributions can be configured in the DSL extension. Configuring the download task isn’t necessary anymore.

The DSL to configure the Java version for the plugin has changed. Builds that let the plugin use the toolchain are not affected.
The Jextract tasks have been reimplemented without the worker API. If you configure the tasks directly in your build, this version will be a breaking change for you. Please try to configure the plugin via DSL, or migrate to the new tasks.

Task dependencies are declared properly, so Kotlin and similar tasks run after Jextract.
Configuration cache doesn’t fail anymore with “executable not found” error.

Tasks that make use of the worker API have been removed and replaced with the new implementations.
Tasks for downloading and extracting Jextract have been removed and replaced with the shared build service.

Migrated example project to pure Java because Kotlin still doesn’t support Java 25 compile target.

Upgraded required JRE and Gradle versions for the plugin:
- Requires Java 21 or higher, was Java 17 before.
- Requires Gradle 8.5 or above that is compatible with Java 21.
- This doesn’t affect Java toolchains.

The code has been migrated to Java to get rid of the Kotlin dependency. This shouldn’t be a breaking change.
If the plugin finds a cached version of a file to be downloaded, its validity is checked by comparing its checksum with that of the download resource.
The JextractStore build service loads the distribution data once when it is created.

This release primarily contains features for better interoperability with Jlink and Jpackage.
- The plugin registers a task that can create JMOD archives containing compiled classes and resources, C headers, and native binaries. The JMOD is exposed as a secondary variant, so it can be consumed by other projects.
- Added better support for testing and running projects where binaries are loaded from the library search path. This can also be useful for linking the artifact into a custom runtime image or native application.

The occurrence order of this plugin and Java plugins in the build script doesn’t matter under any circumstances. A Java plugin could even be omitted in the build script.
Removed an occurrence of eager configuration.
Consolidated the plugin’s implementation.
Added missing Javadoc comments
Updated example project to reflect the plugin features

A local Jextract installation can be configured with the Gradle property org.openjdk.jextract.installation-path instead of the build script DSL. This is the cleaner solution and recommended in the future.
Native header and binary files for a Jextract library can be consumed from dependencies, e.g., another project that uses Gradle Native.

The distributions file should be configured with the jextract.installation.distributions property.
The plugin uses conventions to configure properties instead of setting them. So plugin conventions and user settings won’t be joined anymore.
- The name of a configured library is either used as library name to be loaded per convention, or the list of library names can be completely set by the user in the build script.

The jextract.installation.location property shouldn’t be used anymore and will be removed in the next major release. Local Jextract installation should be configured via user-specific Gradle property.
The jextract.distributions property will be moved to jextract.installation.distributions.