|
||||||||
|
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.
I wouldn't necessarily implement it by changing getParameters, it serves its purpose already. But another entry point in JobManagement would be reasonable. Ideally we'd tie each DSL method to a plugin, which would have to exist in the running Jenkins, something like an Annotation that would just skip over methods not supported (and report it). There's problems with that too, since methods couldn't degrade nicely. I guess the best thing is to make an accessor in JobManagement and let each dsl method do its thing.
I'm going to wait on doing this until we come up with more of a strategy on how we're going to integrate more tightly with Jenkins. E.g. I could return the actual PluginWrapper instance to the dsl method for very tight coupling. That would be useful for things where we need a list of installations at a global level. But it's harder to mock out and our dependencies could get out of control. The alternative is to return a version number for a given name, which would suffice for this issue.