It might make sense that you implement your parsers in Java using a custom plugin. Then you can using sub-classing to solve that problem.

thanks for your answer, it would be a shame as your plugin is very handfull to use. I don't think I would be able to create my own parser plugin from scratch. And I thought my proposal would be a tiny upgrade. When one parser is selected, then a second list is available to provided parameters configured if they are.

it would very pratical to be able to have very little variation around one parser. Because as I described, when lot of parsers are configured, it become painful to maintain when you need to correct one, all other variation need to be corrected also

About the parser number problematic also, could it be possible for a user to have "information" about the parser used like a short sentence that would be configured but admin during the parser creation ?

For instance : 

parser toto => this parser is used for parsing tool XXX messages

parser titi => this parser is used for...

But this is another subject

My plug-in is designed to be extended by small custom parsers. These parsers are as small as the groovy ones, here an example.

You can even add a description for each parser if you implement them natively.

thanks a lot. so instead of using groovy script parser, we can write small java parser.

where must be stored this new java file ?

if there is a parameter in this script, how can the parameter value be configured by the user job ?

The Java files need to be placed into a new plug-in.

Parameters are only supported in the next major release. Example of the planned feature:

• FindBugs parser with parameter
• Configuration of the FindBugs parser

You can then set the parameter during job configuration (UI or pipeline script).

See documentation.