|
||||||||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
By design; parameter values traditionally have been injected as environment variables, so Workflow just followed suit.
Now when using parameter value implementations defined in core, or in a plugin depending on core 1.568+, the new getValue method could be called. For compatibility reasons, we cannot change the type of the existing variables, but we could introduce new variables (or a map variable parameters, etc.) based on the rich types.
Unfortunately there is no clear way to distinguish whether a given ParameterValue implementation is specifying getValue. The Javadoc says it can return this as a fallback, yet the default implementation is null, which may be a legitimate return value in an override. Perhaps we need to just use Util.isOverridden, which is undesirable since it would give incorrect results if there are any proxying implementations, though probably there are not.