This plugin is injecting variables in form of artifactname+tail, so when artifactname has dash this variable become unusuable for shell.

It uses the parameter name for it, not the artifact name.

If i'm entering input value name as KEY then it must be a KEY, no magic substitution.

As they say in Wikipedia: citation needed. Its behavior is documented in the inline help, and the ParameterDefinition Javadoc only states:

The actual meaning and the purpose of parameters are entirely up to users, so what the concrete parameter implmentation is pluggable. Write subclasses in a plugin and put Extension on the descriptor to register them.

FWIW If you want parameter name = env variable set with input, that's a minor improvement at best, not a blocker bug.

As stated in the wiki documentation the variable names are suffixed with _TAIL which makes them perfectly accessible on the command line.

There are different use cases for this plugin and jenkins doesn't provide a convention for a single parameter being able to create multiple variables, so I just created my own.

If you enter a parameter value from a command-line job trigger for KEY it will be echoed back as KEY_VERSION, which I admit is awkward. But until jenkins adds a way to define multiple variables from a single parameter awkward is the best you will get from this plugin.

If you have configured input parameters from other plugins and want change them to this plugin - you fail. Because it creates other values. Storing additional variables is ok. But input parameter must be the same that people is entering. This maybe easily fixed with just adding entered value to environment in addition to your existed.

Btw, i'm unable to PR this simple improvement because of annotated framework. It's a first plugin in jenkins that i can't just open in IDEA and start working... Real dependencies are in profiles, java sources in wrong directory, wrong package name. Do you really need this complexity just for 3 classes?