javapackager/JavaPackager v2.0.0-rc1

on GitHub

Breaking changes

• New coordinates, packages and Gradle plugin id. The project moved to the javapackager organization. Everything that was named io.github.fvarrui is now io.github.javapackager:
  • Maven groupId: io.github.javapackager (was io.github.fvarrui).
  • Gradle plugin id: io.github.javapackager (was io.github.fvarrui.javapackager.plugin).
  • Java packages: io.github.javapackager.*, e.g. the Gradle task type io.github.javapackager.gradle.PackageTask (was io.github.fvarrui.javapackager.gradle.PackageTask).
  • Versions up to 1.7.6 remain available under io.github.fvarrui.
• macStartup now defaults to UNIVERSAL (was SCRIPT). macOS apps use the new native launcher, which runs natively on both Apple Silicon and Intel. Set macStartup to SCRIPT to keep the previous launcher.
• Gradle PackageTask boolean getters are now getX() instead of isX() (getBundleJre(), getGenerateInstaller(), getAdministratorRequired(), ...), because Gradle 9 ignores Boolean properties with is getters. Build scripts that set them (bundleJre = true) don't change; only code that calls the getters does.
• Maven zipball and tarball names now follow the name and version properties, like the Gradle plugin and the README: ${name}-${version}-${platform}.zip / .tar.gz (#489). They used to come from build.finalName, so the name changes if name differs from the artifactId; zipballName and tarballName still override it. This also stops two executions in one build from overwriting each other's archive.
• AppImage and RPM file names now follow the other installers: ${name}_${version}.AppImage and ${name}_${version}.rpm (#481).

How to upgrade

Maven:

<plugin>
    <groupId>io.github.javapackager</groupId>
    <artifactId>javapackager</artifactId>
    <version>2.0.0</version>
    [...]
</plugin>

Gradle:

buildscript {
    repositories {
        mavenCentral()
        gradlePluginPortal()
    }
    dependencies {
        classpath 'io.github.javapackager:javapackager:2.0.0'
    }
}

apply plugin: 'io.github.javapackager'

task packageMyApp(type: io.github.javapackager.gradle.PackageTask, dependsOn: build) {
    [...]
}

To keep the previous macOS launcher:

<macConfig>
    <macStartup>SCRIPT</macStartup>
</macConfig>

New features

• #305 Default application arguments with the new appArgs property (GNU/Linux and macOS; Windows support is still pending).
• #477 WiX Toolset 4+ support: if wix is in PATH it is used to build MSI and MSM files, otherwise JavaPackager falls back to WiX 3 (candle and light). See the Windows tools guide.
• Native macOS launcher (nativeJavaApplicationStub) for UNIVERSAL, X86_64 and ARM64 startup types. It should fix the Rosetta and macOS 15 launch problems reported in #448, #449 and #389; please confirm in those issues.
• #485 Gradle 9 support: the Gradle plugin no longer uses deprecated Gradle APIs (JavaPluginConvention, Task.getProject() at execution time, TaskContainer.create()), and the launch4j Gradle plugin is updated to 4.0.0.
• -SNAPSHOT versions are published to the Central Portal snapshots repository (see the README).

Fixed issues

• #421 Customized JRE missing modules: jdeps now analyses the libs folder and the runnable JAR.
• #439 Customized JRE generation failed since 1.7.6 when dependencies split a package across JARs (e.g. netty): jdeps now falls back to the class path when it fails on the module path.
• #463 AppImage generation failed because appimagetool moved to a new download location.
• #470 GNU/Linux startup script didn't quote arguments, so arguments with spaces were split.
• #473 macOS app with administratorRequired=true didn't include the launcher, so it didn't start. This may also fix #398; please confirm there.
• vmArgs containing spaces broke the Windows EXE built with Launch4j, and were split by the macOS SCRIPT launcher.
• appArgs containing spaces were split by the macOS SCRIPT launcher.
• DMG generation failed intermittently with hdiutil: ... Resource busy or Resource temporarily unavailable; hdiutil commands are now retried.
• #484 Registering a Gradle PackageTask without applying the plugin failed with a NullPointerException; it now fails with a message saying to apply io.github.javapackager, and the plugin can also be applied after registering the task.
• #369 The Inno Setup "Launch" checkbox ran the app as the administrator who approved the install instead of the logged-in user (unless administratorRequired is true).
• The classpath property broke the GNU/Linux startup script (java -jar took the whole classpath as a file name), so the app didn't start.
• #444 Maven builds that can only reach Maven Central couldn't resolve the plugin: its POM declared the launch4j Gradle library, only published on the Gradle Plugin Portal. Maven users now only need Maven Central (Gradle users still need gradlePluginPortal(), see the README).
• Maven API artifacts (maven-plugin-api, maven-core, ...) were published with runtime scope, so Maven users downloaded old Maven jars they didn't need. They are now provided.

Maintenance

• Updated dependencies, including commons-compress 1.28.0, plexus-utils 4.1.0, commons-io 2.22.0, commons-lang3 3.21.0, velocity-engine-core 2.4.1, jdeb 1.14, launch4j-maven-plugin 2.7.0 (part of #465) and the launch4j Gradle plugin 4.0.0. The plugin still runs on Java 8.
• Smoke tests on every push: the Maven and the Gradle plugin package the same sample app (samples/hello-world) on GNU/Linux, Windows and macOS (Apple Silicon, every macStartup type) and check the generated apps and installers. On macOS the app is also installed from the DMG and from the PKG and opened through Launch Services, like from the Finder (based on #487 by @maths22). It replaces the old HelloWorldMaven and HelloWorldGradle sample repositories, now archived.
• The macOS SCRIPT launcher (universalJavaApplicationStub.sh) is now maintained in this repository, since the upstream project is deprecated. The native macOS launcher is maintained in javapackager/nativeJavaApplicationStub (formerly universalJavaApplicationStub).
• Documentation: WiX 4+ installation, gradlePluginPortal() in the Gradle setup (#444), and building the plugin with a JDK 17+.