[FIXED JENKINS-15796] NoClassDefFoundError: 'Could not initialize class org.jvnet.hudson.Windows$MEMORYSTATUSEX' from SwapSpaceMonitor.
Not fixing actual linkage error—JNA issue of some kind—but ensuring that Jenkins reports it only once.

Integrated the new version of Stapler that includes the fix.

[FIXED JENKINS-16474] Winstone and executable WAR upgraded to actually support --httpKeepAliveTimeout.

These are one time URLs, and this change aligns them from other /static/
links that serve 365 days expiration period.

[FIXED JENKINS-17087] getSortedDescriptorsForGlobalConfigUnclassified needed to avoid clobbering GlobalCrumbIssuerConfiguration in Jenkins.doConfigSubmit.

(Ah, the joys of dynamic typing!)

Disable authenticode verification on jenkins.exe and jenkins-slave.exe
by generating a proper application configuration file.

See: http://msdn.microsoft.com/en-us/library/cc656914.aspx
See: http://msdn.microsoft.com/en-us/library/bb629393.aspx
See: http://support.microsoft.com/kb/936707

Added backward compatible data loader and a corresponding test case.

HyperlinkNote shouldn't emit the absolute URL.

b5ed3199 already caught linkage errors but then unconditionally returned false from Util.isSymlink, which is wrong;
we want to fall back to the generic File.canonicalPath comparisons in this case.

There are several incompatibilities in XStream 1.4 that resulted in our
changing the core, but according to the text search on all the public
plugins, none of these changes affect the 600+ plugins we have today.

However, it is still possible that there are some parts of XStream 1.3
that plugins depend on but the core doesn't depend on --- we won't be
able to tell those problems at this point.

Not sure what has happened --- perhaps some of the markers were off and
that confused the update script?

Will need to watch out for the next RC run.

Fixes: Maven2 builds with non-standard test mojos failed.

[FIXED JENKINS-16844] MenuItem.post allows context menu items like Build Now to send a POST request.
Currently just shows a hover notification; TBD if there are use cases for displaying the response.

Traditionally, matrix axis values are only exposed as "build variables", and it was up to individual build steps and others to treat them equally like environment variables.

However, in practice, this distinction between environment variables vs build variables didn't serve any useful purposes, and the down side (of some plugins only expanding env vars in the ${VAR} notation and not build variables) was probably bigger than whatever benefit this distinction was supposed to bring.

In this fix, we are exposing matrix axis values also as environment variables. This will make them recognizable from plugins that only expand environment variables, such as parameterized trigger plugins as indicated in the original bug report.

This was motivated by pull request #701 but fix was made differently.

Introduced ${ITEM_FULL_NAME} to address the ticket without causing the
backward compatibility problem.