|
||||||||
|
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 jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
For the case of web service client libraries, again I do not think you want to run these as plain blocking Java calls (for example using an existing grape) because they involve network I/O which would block the CPS VM thread and not survive interruption. You could write a Step using asynchronous I/O. Or you could use DurableTaskStep, such as simply via sh, or perhaps we need a variant that runs the local JRE/bin/java with a main class, or runs a forked groovy interpreter, etc.
I had no particular plans for cross-server code reuse other than via plugins with steps. The GroovyShellDecorator extension point allows other options. If Grape supports Groovy-source-based libraries then supporting it from Workflow would presumably work via this extension point.