How to get the version automatically from Gradle or Maven?

[aadrian]

How to get the version automatically? (from Gradle and Maven)?

@CommandLine.Command(
        name = "niceName", version = "niceName v1.0.1",
        ....

This version information is already defined in any Gradle or Maven build file in the version property.

Would be really helpful if this property would be available in the annotation, to be able to have something like e.g.:

@CommandLine.Command(
        name = "niceName", version = "{{ name }} v{{ version }}",
        ....

Thank you

[remkop]

Would this meet your needs: https://github.com/remkop/picocli/blob/master/picocli-examples/src/main/java/picocli/examples/VersionProviderDemo1.java

This is a IVersionProvider implementation that returns version information from a version.txt file in the classpath. It also contains a Gradle snippet that updates the content of this file with the project version, name and build time. Together they provide what you have in mind, I think...

[aadrian]

Would this meet your needs ...

@remkop Thank you for your help!

This solution looks interesting. We are using something similar with GIT commit details too, for webapps where this info also needs to be displayed on pages.

Would it be possible to skip the entire version.txt file completely? and have directly as static final field(s) created at compile/built time? With Groovy AST Transform at compile time, this might seems possible, but not sure how simple would be for other JVM based languages.

[remkop]

@aadrian That may be possible but not sure how. If you find a way, please share it so that the whole picocli community can benefit!

[aadrian]

@remkop This https://picocli.info/#_dynamic_version_information looks interesting, especially the Meta-Inf https://github.com/remkop/picocli/blob/master/picocli-examples/src/main/java/picocli/examples/VersionProviderDemo2.java example, since a correctly configured application will always generate that file with the version number.

Unfortunately that example just picks the first Meta-Inf that has a version and a title from the classpath. I'm not sure how to enforce that the 'name' is unique among all JARs (because 3rd party dependencies).

[remkop]

Unfortunately that example just picks the first Meta-Inf that has a version and a title from the classpath

No, that statement is incorrect. The example loops over all manifests in the classpath, until it finds (see the isApplicableManifest method on line 69) a manifest that has "picocli" as its implementation title, then prints attributes from that particular manifest.

An application could use a different filter, or a similar filter but select a different implementation title.

[aadrian]

The example loops over all manifests in the classpath, until it finds (see the isApplicableManifest method on line 69) a manifest that has "picocli"...

Yes, but the Implementation-Title property of many JARs is not correct, so the first one in the classpath wins.

An application could use a different filter, or a similar filter but select a different implementation title.

Indeed, that's a good workaround.

A "marker" property different than Implementation-Title could ensure uniqueness since the manifest specs seem to allow custom property names.

[remkop]

I see what you’re saying now: Could picocli not include a version provider implementation that looks for a custom property in the manifest and prints version information from the first jar in the classpath that has a manifest with that custom property?

Perhaps I was focused too much on the built-in attributes like Implementation-Version or Specification-Version.

Actually all my questions can be answered with the custom property you proposed. The value of the property could be the value that should be printed, and this could be multi-line by embedding %n character sequences. For example:

picocli-version: My App v1.2.3%nSome more info 

Picocli could include a PicocliJarManifestVersionProvider that prints out the value of all picocli-version properties it finds in manifest files in jars on the classpath.

So the build should ensure the jar includes this property in its manifest. The documentation should clarify how to accomplish that with popular build tools.

Do you think you’ll be able to provide a pull request for this?

[samrocketman]

This issue gave me some hints for how to store the Gradle version into my application Jar. Thanks!

Application is a Groovy CLI compiled by gradle and distributed as a java uber jar.

samrocketman/cloneable@2f0bdd7

[helpermethod]

It would be really great if Picocli would provide such a provider by default. I'll may take a stab at this.

[remkop]

@helpermethod I am not sure if the library should include such a version provider implementation.
It seems more appropriate to have a good example in the documentation.

This ticket #1663 shows how simple the application code for this can be.
I just have not gotten around to verifying this and adding it to the documentation.

[helpermethod]

@remkop Makes Sense! My point is that setting the version number at build time is such a common problem that it probably would make sense to solve this once. But showing an example would be okay I guess.