Version having x.x.x-SNAPSHOT or similar make the build fail

[Sami32]

Caused by: java.lang.IllegalArgumentException: Package version is not allowed to contain colons or hyphens
    at com.github.gino0631.pac.PackageBuilder.build (PackageBuilder.java:128)
    at com.github.gino0631.pac.maven.PackageMojo.execute (PackageMojo.java:171)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
    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:956)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)

pac/pac-core/src/main/java/com/github/gino0631/pac/PackageBuilder.java

Line 127 in fbb0dcc

if (pkgVer.contains(":") || pkgVer.contains("-")) {

Of course manual editing can solve it but i think that a better version handling should be prefered, like automatic truncating.

[gino0631]

Do you propose just to remove the hyphens, e.g. to make 1.0SNAPSHOT if 1.0-SNAPSHOT is specified?

[Sami32]

I was more thinking about truncate the characters from the colon or hyphen until the end to avoid that annoying failure, as it seem the safest way to me.
I'm afraid that leaving SNAPSHOT could generate problem, as i'm not familiar with Arch Linux.

pkgver

The version of the software as released from the author (e.g., 2.7.1). The variable is not allowed to contain colons or hyphens.
The pkgver variable can be automatically updated by providing a pkgver() function in the PKGBUILD that outputs the new package version. This is run after downloading and extracting the sources so it can use those files in determining the new pkgver. This is most useful when used with sources from version control systems (see below).

[Sami32]

Package versions should be the same as the version released by the author. Versions can include letters if need be (eg, nmap's version is 2.54BETA32). Version tags may not include hyphens! Letters, numbers, and periods only.

https://wiki.archlinux.org/index.php/Arch_packaging_standards

[gino0631]

OK, the default for packageVersion is ${project.artifact.selectedVersion.majorVersion}.${project.artifact.selectedVersion.minorVersion}. If one specifies a 1.0-SNAPSHOT manually, it would be quite strange to change it to something else.

[Sami32]

In fact it seem that ONLY periods are accepted in pgkver, with letters and numbers.

[gino0631]

Not sure if I understand the problem. If one wants 1.0b, or 1.0a, or 1.0beta, or anything else, this can be specified as a package version as long as it is a valid version number. What is the point of specifying 1.0-SNAPSHOT and expecting it to get replaced with beta or anything else?

[Sami32]

The version come from the Maven POM ${project.version} used in all the other builds.
That make the maintaining more easy.

I'm just reporting the issue, as i can fix it with some more code added while keeping the main version unchanged.

[gino0631]

Just trying to understand the problem and the proposals. OK, so you specify ${project.version}, and get the exception because of the -. Not specifying the version, so that it becomes major.minor by default, is not an option in your case, and you expect ${project.version} to get replaced to something valid?

[Sami32]

Arrrgh...my bad. I didn't test to use the default version value 😞
I'm just to used to set it that way for most other Maven build plugin.
Habits can kill say the proverb ;)

Thank you for having pointed me to the more easy fix 😉

[Sami32]

Nope, the default version 0.0 value given is fine for testing build but it will not fit a release build criteria as it doesn't use project.version if nothing else exist.

So an other alternative could be to use project version if major.minor doesn't existing in the pom.xml, only if project.version doesn't contain illegal characters.

In fact, as we have something like that 0.0.2-SNAPSHOT, we need at least ${PRODUCT_VERSION_MAJOR}.${PRODUCT_VERSION_MINOR}.${PRODUCT_VERSION_BUGFIX}
The 4th field being the build number is more rarely used and set more or less arbitrary for snapshot.

That was my 2 cents.

[Sami32]

Arch Linux documentation seem really be sparse and given piece by piece dependant where you take it:
https://wiki.archlinux.org/index.php/creating_packages#pkgver.28.29

[gino0631]

OK, I'll take a look.

[Sami32]

As you suggested something like 0.0.1SNAPSHOT version, when project.version is 0.0.2-SNAPSHOT, should be the best way that i can think of now, that's said i'm open to better suggestions because i tried to return that in all the sens and didn't arrived to a "perfect" choice.

The fact to have only major and minor version will make the repositories artifact resolver don't see any difference while the project version 0.0.x will push update.
And the mess of ArchLinux documentation saying no hyphen, no space there, no coma here.... As at least one say only dot and numbers and letter i think that sticking to the more strick rules will avoid possible issues raising among older or "derivate" of ArchLinux.

[gino0631]

Currently, the default is:
${project.artifact.selectedVersion.majorVersion}.${project.artifact.selectedVersion.minorVersion}

So, if your project's version is 0.0.2-SNAPSHOT, you will get 0.0 indeed (as the third number is omitted). I will change the default to include all three digits, to be more compatible with Maven versioning.

In any case, it is all up to the user. For example, in more complicated scenarios buildnumber-maven-plugin can be used to generate SCM-based numbers or timestamps to be included in the packageVersion.