|
||||||||
|
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.
Hi Jesse,
Thanks for getting back to me again.
The reason I'm looking at the workflow-plugin is because it allows a programmatic interface, and it is potentially a very powerful means to share jenkins job setups across multiple teams and engineers, and even more so if it can work in a way that provides the extensibility and reuse that the groovy language can offer. This means things like class inheritance, interfaces and other OO techniques are desirable and of particular interest to me. Moreover, the flows I'm looking at are inherently quite complex and I would ideally like to generate infra for them that could be used by a number of people/teams - not just copy/pasted.
If I go with conservative, I fear I will end up with multiple copies of the same rehashed code for each instance where it is actually used - and that means more places for it to go wrong and maintain.
So what would really set the workflow-plugin apart from e.g. a typical multijob setup is the ability to do some of the less "conservative", more "groovy" things![]()
Regards,
Tom.