The JDK's jarsigner has the parameters "providerClass" and "providerArg", but Ant's signjar task does not. (These parameters are necessary for signing JARs using GlobalSign certificates which are stored on SafeNet-USB-Tokens.)
I guess they are also needed in verifyjar. It shouldn't be too difficult to add new attributes. Maybe we should provide support for nested <arg>s so peopke can use whatever flag they need and don't have to wait for us to provide the implementation and a new release?
<arg> lacks validation. See e.g. comments to https://github.com/apache/ant/pull/64
Sure, I'm not suggesting to add <arg> instead of specific attributes but rather as a workaround until we add such specific attributes.
>> Maybe we should provide support for nested <arg>s so peopke can use whatever flag they need and don't have to wait for us to provide the implementation and a new release? For a task like this one, where we wrap a command/tool which has too many permutations/combinations, plus no real specification to follow, I think it's better to support a generic <arg>s element for it. As for validation of these specified args, in context of this and similar (keytool based) tasks, I am not too sure we doing that validation, by exposing specific attribute names to the task, adds much value. What I mean is, ultimately we end up doing almost the same set of validations that keytool would have done. Plus, recent bug/enhancement reports show that keytool has too many permutations of arguments that behave differently in context of what the command is, adding to the complexity of such validations.
Addes for Ant 1.9.14 and 1.10.6.