|
||||||||
|
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/groups/opt_out.
Here's a first pass at solving this. I have the approach that most additions should be plugins. When I looked at the Trigger extension point I was sceptical that this should be a plugin. The CronTab and CronTabList classes did not want to cooperate.
Then there is the is the configuration. In order to make the parameterized schedule enabled only for projects with parameters I seem to have forced the user to re-enter the config screen after setting parameters. This does not flow well.
Now that I've implemented it as a plugin, I suspect it should be in core. Else the Trigger extension point needs some refactoring to support different kinds of triggers. It's my opinion that the Trigger was nearly already in need of refactoring. This is evidenced by Trigger.getSpec(), checkTriggers is static but other Trigger implementations may not be the least bit interested in CronTabList. For my part, I needed to extend CronTab to support parameters stored with each.
I'm interested to hear the opinion of others closer to, with more experience in, the jenkins-core.
https://github.com/jwmach1/parameterized-scheduler