Provide more context information to IVersionProvider.

Thanks for a truly awesome and well-thought-out library!

I’d like to request some additions to the IVersionProvider approach. The problem is that it requires some static strategy that will be instantiated when the annotations are processed, and this make it very hard to provide any dynamic information for subclasses. That is, if I wanted to create a convenience base CLI application class that would automatically look up a version, currently each actual CLI application has to implement a lot of boilerplate. Let me explain.

Our applications use Maven, and it’s straightforward to have the a properties file such as MyApp-config.properties which Maven automatically updates with the version number when it builds the project. Currently for one application I’m using a version provider that simply looks up the config properties from the program resources. This works fine for a single application, but it’s hard-coded to know the actual application class (in order to use its class loader and find the properties file in resources).

What we need is more contextual information in the IVersionProvider interface which would tell the strategy the name of the class for which a version is being retrieved. Something like this:

public interface IVersionProvider {
  String[] getVersion(Class<?> commandClass) throws Exception;
}

Since you’re processing the class annotated by the @Command annotation anyway, picocli knows what class it’s getting metadata for, so it can pass that class to getVersion(). This would be immensely helpful. Then we would simply need to use something like this:

@Command(name = "foobar", description = "…",
    versionProvider = ResourcesVersionProvider.class, mixinStandardHelpOptions = true)
public class Foobar {
  …
}

Now the ResourcesVersionProvider would receive FooBar.class the getVersion() call, and it would know where to find the version information (which Maven would have updated). Each CLI application could reuse the ResourcesVersionProvider strategy class and wouldn’t have to make a new one each time.

If you like the idea but don’t have the time, I could look into contributing the changes if you’re open to help. (P.S. We could really use a INameProvider as well, for the same reasons. We put that in the POM, so why not let Maven update that for us as well.)

[remkop]

Hi @garretwilson, no worries about response time. I can relate. 😃

There is a @Spec annotation which I plan to reuse for this, but it is currently only injected into command classes, not in the version provider implementation class. This will take some work, including updating the annotation processor. Not huge, I just did not get around to it yet.

For now I would suggest you go with the workaround you mentioned, so then hopefully a later picocli version will allow you to remove some code.

[remkop]

@garretwilson, All,

picocli 4.2.0 has been released, including this feature. Enjoy!