A constant is not that good because of the way that the java compiler optimizes primitive constants. Let's say ToGerritRunListener.ORDINAL = 15 and BFARunListener.ORDINAL = ToGerritRunListener.ORDINAL-5 the compiler would put BFARunListener.ORDINAL = 10 in the byte code. If ToGerritRunListener.ORDINAL where to be changed BFARunListener would need to be recompiled against that new version. But that is probably a small issue, I don't think that the ordinal would ever change in reality.
Having events in the GT is a good idea, but the dependency to GT in this case is optional. GT is in this scenario in its RunListener calling its extensionpoint if there is anyone that wants to add a message to the approve that it is sending to Gerrit. And the build failure analyzer might want to do that but it needs to run its analysis first. Hence the runlistener in the BFA needs to run before the GT RunListener. As I said in this case I am the maintainer of both plugins so I don't have an issue with using ordinals here, my mind was just doing hypotheticals like the one above. Or (another hypothetical) what if it is two proprietary plugins that are independent of each other but my plugin needs to run between them. I guess my concern is around the randomness of using arbitrary numbers that can be chosen at the whim of the developer and that could lead to random problems. But it is probably as you guys say that it is a non problem and adding more complexity could just worsen the situation. Robert Sandell Software Tools Engineer - SW Environment and Product Configuration Sony Mobile Communications > -----Original Message----- > From: [email protected] [mailto:jenkinsci- > [email protected]] On Behalf Of Kohsuke Kawaguchi > Sent: den 29 november 2012 01:04 > To: [email protected] > Subject: Re: More sorting options for @Extension? > > > 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
