[JENKINS-3752] support BuildWrapper ordering

[timja]

I have a few BuildWrappers that need to execute in a fixed order, which is
unfortunately not the order the auto-discovery produces. We should add some way
to influence this:

• allow users to drag&drop BuildWrappers like they can for Builders
• or support ordering through annotations.
  e.g. @Extension @Preceeds( {AnotherBuildWrapper.class}

  )
  @Follows(

  {BuildWrapper1.class, BuildWrapper2.class}

---

Originally reported by huybrechts, imported from: support BuildWrapper ordering

• status: Closed
• priority: Major
• resolution: Fixed
• resolved: 2009-12-24T12:45:22+00:00
• imported: 2022/01/10

[timja]

jglick:

There is now (added recently) an 'ordinal' attribute on Extension for this purpose.

As its Javadoc warns, this should not be considered the first choice - if a
particular kind of extension can be mechanically ordered on some more natural
basis then that would be preferable. Can you give some details of why your
BuildWrapper's need to be run in a particular order?

@Succeeds/@Precedes or similar would probably cause headaches; at least for
NetBeans modules we have found such a system to be impractical, and so switched
to a simpler numeric ordering:

http://wiki.netbeans.org/FolderOrdering103187#section-FolderOrdering103187-ProblemsWithCurrentState

[timja]

huybrechts:

I have two build wrappers in custom plugins :

• one resets a virtual machine to a previous snapshot
• the other starts an application server on a separate node

This needs to happen in this order, but I could not find any way to do this.
In the end I resorted to using @Extension for one and custom registration for
the other because then the order is guaranteed.

Extension.ordinal will work for me...

[timja]

kohsuke:

Note that this feature doesn't work as @Extension is has @Retention(SOURCE) and inaccessible during the runtime.

See https://sezpoz.dev.java.net/issues/show_bug.cgi?id=6 for the relevant discussion.

[timja]

scm_issue_link:

Code changed in hudson
User: : kohsuke
Path:
trunk/hudson/main/core/src/main/java/hudson/Extension.java
http://fisheye4.cenqua.com/changelog/hudson/?cs=24932
Log:
[FIXED JENKINS-3752] @Extension.ordinal() should now work, at least those that are specified on a class. As Jesse points out in https://sezpoz.dev.java.net/issues/show_bug.cgi?id=6, more changes are needed to make it work on methods and fields, but those are less frequently used. In 1.340.

[timja]

jglick:

Note that ordinal() would work trivially with just SOURCE retention if ExtensionFinder.SezPoz were calling item.annotation() in the usual way, rather than relying on ExtensionList.sort to do this retroactively based on runtime reflection. The current approach breaks the encapsulation whereby only EF.SZ knows about the @Extension annotation and its semantics.

The proper fix is likely to change the ExtensionFinder API to return a List<(T,int)> so that subsequent sorting can operate on the pairs created by arbitrary means by the EF impl; or else to not resort returned lists at all (do the sorting in EF.SZ.fE) and not support cross-supplier ordering (i.e. cannot intermix items from SezPoz and Plexus or whatever).