than the default view - In the view object appended the system message
to the view description so that the system message now displays in all
views.

This came out of the conversation with Nicolas.

When QueueTaskDispatcher vetos the assignment, a buildable item might
stay buildable and unexecuted. Ane he found that it doesn't get retried,
despite the MaintainTask class that attempts to do so.

The issue is that the maintain() method actually doesn't try to assign
buildable tasks to executors. That happens inside the pop() method.
I think this goes against the original design of the maintain() method,
which is a giant synchronized block that moves all the relevant actors
from one state to another.

So I'm moving this code into the maintain method. In this way,
MaintainTask will automatically reattempt to assign buildable items
to executors, and scheduleMaintenance() and maintain() will really
do the same thing, and it solves the original problem.

This reverts commit acef92c4.
2.2.2 has http://jira.codehaus.org/browse/MRELEASE-724 and it prevents
me from running a release.

Bundle slf4j binding to the war.
See the comment in war/pom.xml for detailed discussion.

This is fundamentally a "damned if I do, damned if I don't" situation,
but given that JENKINS-12334 is a fatal error, and the downside of
bundling the binding jar is "multiple binding" warning, it seems like
the lesser evil is to bundle it and risk some warnings.

The motivation of this is to enable test code to inject components from Jenkins, which means we need a single Injector that can see all of those, including @TestExtension and regular @Extension. Then I realized that the current implementation is broken, as it creates two independent Injectors. This has other undesirable side effects like @TestExtension components not being able to inject @Extensions, etc.

I briefly experimented with hierarchical Injectors (where we first create Injector that loads @Extension then create another that loads @TestExtension as a child), but this was hard to get right as we have no control over which ExtensionFinder gets instantiated first --- we'd be at the mercy of SezPoz.

So the eventual approach is to allow a single GuiceFinder to recognize multiple annotations. This also works well with our using child injector for installing plugins without restart

removing static is a binary incompatible change.

environment.

... because the positioning is fixed. Perhaps it's better to let the
CSS class name control if it's left-sticky or right-sticky.

If the sections unfold/fold etc and layout changes, the save button
needs to update its location