[assemble] Enable zero value in major part of version number

[GrolarDan]

Task List

• [ ✅ ] Steps to reproduce provided
• [ ✅ ] Stacktrace (if present) provided
• [ ❌ ] Example that reproduces the problem (link to git repository is ideal)
• [ ✅ ] Full description of the issue provided (see below)

Steps to Reproduce

Set project version to number with zero major part (0.1.4)
Run assemble goal

Expected Behaviour

Assemble goal is executed without an error.
SEMVER version pattern validation supports zero in major part see here

Actual Behaviour

The goal execution fails with an error.
org.jreleaser.util.JReleaserException: JReleaser has not been properly configured.
The first number in an app-version cannot be zero or negative (0.1.4).
Advice to fix: Set a compatible 'app-version' value. Valid versions are one to three integers separated by dots.

Environment Information

• Operating System: Windows 11
• JReleaser Version: 1.2.0
• JDK Version: 17.0.2

Please paste stacktraces from [out|build|target]/jreleaser/trace.log.

org.jreleaser.util.JReleaserException: JReleaser has not been properly configured.
The first number in an app-version cannot be zero or negative (0.1.4).
Advice to fix: Set a compatible 'app-version' value. Valid versions are one to three integers separated by dots.

at org.jreleaser.engine.context.ModelValidator.validate(ModelValidator.java:47)
at org.jreleaser.workflow.WorkflowImpl.<init>(WorkflowImpl.java:42)
at org.jreleaser.workflow.Workflows.assemble(Workflows.java:41)
at org.jreleaser.maven.plugin.JReleaserAssembleMojo.execute(JReleaserAssembleMojo.java:78)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)

[aalmiray]

Thank you. Could you also post the full stacktrace found in target/jreleaser/trace.log?

[GrolarDan]

trace.log

[aalmiray]

This is not a regression. jpackage applies additional restrictions on app-version (the error message is logged as is). For this reason the jpackage assembler lets you define a custom appVersion. This is not really a bug.

[GrolarDan]

Here is my whole configuration

<assemble>
    <jlink>
        <dmk-app-jlink>
            <active>RELEASE</active>
            <imageName>${project.artifactId}-${project.version}</imageName>
            <executable>${project.artifactId}</executable>
            <exported>false</exported>
            <mainJar>
                <path>${project.build.directory}/${project.artifactId}-${project.version}.jar</path>
            </mainJar>
        </dmk-app-jlink>
    </jlink>
    <jpackage>
        <dmk-app>
            <active>RELEASE</active>
            <jlink>dmk-app-jlink</jlink>
            <applicationPackage>
                <appName>${appName}</appName>
                <vendor>MASCI</vendor>
                <appVersion>${project.version}</appVersion>
            </applicationPackage>
            <linux>
                <types>deb,rpm</types>
                <maintainer>daniel@masci.cz</maintainer>
            </linux>
            <windows>
                <types>msi</types>
                <appName>${appName}</appName>
                <installDir>${appName}</installDir>
                <dirChooser>true</dirChooser>
                <console>true</console>
                <menu>true</menu>
            </windows>
        </dmk-app>
    </jpackage>
</assemble>

In applicationPackage I set the appVersion to 0.1.4 and get the error.
How can I set custom appVersion to 0.1.4?

[aalmiray]

You can't use 0 as initial value as far as I can tell. JReleaser's jpackage assembler lets you configure a different value for appVersion so that the project's version stays the same, even if it's not accepted by jpackage.

[GrolarDan]

I don't agree.
0 is absolutely eligible value. This way I can't create installation package with 0.1.4 version.
In SemVer specification it is not recommended but not prohibited.

[aalmiray]

I'm sorry but it's not JReleaser the one that makes the rules, it's the jpackage command line tool. See for yourself when running it manually

$ jpackage --main-jar ~/tmp/app/target/app-1.0.0.jar --app-version 0.1.4 --input .
Bundler Mac DMG Package skipped because of a configuration problem: The first number in an app-version cannot be zero or negative. 
Advice to fix: Set a compatible 'app-version' value. Valid versions are one to three integers separated by dots.

[GrolarDan]

This is strange.
I can call jpackage --add-launcher DMK=jpackage.properties @jpackage.txt
where jpackage.txt contains

--module-path .\target\classes
--module dmk.pg.jreleaser/dmk.pg.jreleaser.Main
--name dmk-jreleaser
--win-dir-chooser
--app-version 0.1
--install-dir dmk-jreleaser
--copyright "Copyright 2020 DMK, Czechia"
--vendor DMK
--win-menu
--win-shortcut
--win-menu-group DMK
--type msi

and jpackage.properties

module=dmk.pg.jreleaser/dmk.pg.jreleaser.Main

and the output file is dmk-jreleaser-0.1.msi

I'm using 17.0.2 jpackage version

[aalmiray]

I see. Looks like jpackage on OSX is more aggressive with the version number than on Windows. If that's the case then JReleaser can relax the check when running on Windows. I must check whats the behavior on Linux before committing a fix

[aalmiray]

I've got confirmation that leading 0 is only disallowed on OSX. I'll update the code with this new information.

[aalmiray]

Released in v1.3.0 -> https://github.com/jreleaser/jreleaser/releases/tag/v1.3.0