I tend to agree with Jesse here that more sophisticated ordering control
seems to have a diminishing return.
Aside from conspiring between plugins about ordinals (for example
GerritTrigger RunListener can make its ordinal a published constant
value that other guys can depend on), if you anticipate that something
needs to happen before the gerrit trigger plugin, what if gerrit trigger
defines its own events that allow other plugins to do stuff before/after
it does what it does?
On 11/27/2012 06:27 AM, Jesse Glick wrote:
On 11/27/2012 08:38 AM, Sandell, Robert wrote:
I think it would be great if I could annotate my RunListener with for example
@Extension(beforeClass=”org.jenkins-ci.plugins.someplugin.ThatRunListener”)
or
@Extension(afterClass=”org.jenkins-ci.plugins.someplugin.ThatRunListener”)
@Extension(beforePlugin=”some-plugin”)
@Extension(afterPlugin=”some-plugin”)
My $0.02: I once created a scheme for another module system that worked just
like you describe. It was a usability disaster (e.g. cycles encountered only
when testing
novel combinations, extensions trying to arrange themselves between other
extensions in long-obsolete plugins) and eventually had to be simplified to
just use ordinals.
I don’t know how to find and handle cyclic references
Finding them is easy enough with a topological sort. Reporting the minimal
cycles preventing a topological sort is harder but doable (as I found). As to
recovering from
the situation sensibly—well, I think you just load the affected extensions in
an arbitrary order and hope for the best.
If you want to run before the Gerrit trigger, then pick a smaller number. That
is about as loosely coupled as you can get.
--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Nectar, our professional version of Jenkins
