now it is done properly on Javascript side so the current server
implementation triggers javascript errors.

Result can be observed on DynamicComboBox within ui-samples-plugin

Solves the issue for newly created builds by not attempting to persist the original file upload record, which is useless after the build has run (the fileParameters dir in the build already archives them).
Does not help loading pre-fix builds in which the upload temp file has been deleted; for these, you must manually delete <file class="org.apache.commons.fileupload.disk.DiskFileItem" serialization="custom">…</file> from the build.xml.
(Did not find a straightforward way to just instruct XStream to ignore this bit of XML: it is easy to avoid serializing a field, but deserializing is different.)

[FIXED JENKINS-15940] WARNING: Caught exception evaluating: descriptor.getHelpFile(attrs.field). Reason: java.lang.NullPointerException

[FIXED JENKINS-15836] Slave's Name should be trimmed of spaces at the beginning and end of the Name on Save

pages.

of project with maven-failsafe-plugin

Do not inject testFailureIgnore to
maven-failsafe-plugin:integration-test because it doesn't exist and
causes an NPE with Maven2.
Only insert it for maven-failsafe-plugin:verify.

"When running on Java 5, must still load DiskSpaceMonitor/TemporarySpaceMonitor, even though they will show N/A."

This reverts commit 8ad62f77.

[FIXED JENKINS-15869] When running on Java 5, must still load DiskSpaceMonitor/TemporarySpaceMonitor, even though they will show N/A.
Returning null from an @Extension method does not seem to work reliably, and is not supported by SezPoz.
If desirable to hide a monitor column in $server/computer/, add a boolean isEnabled() method interpretable in Jelly.

Wrap history iterable to hide class implementation details.
Jelly was getting confused by the history underlying class being implemented
as an extension of Map

[JENKINS-13202] 646154f1 refinement: resolveSymlink is documented to return null, not throw an exception, when called on a regular file.

The bug was actually already fixed and moreover this could cause that fireCompleted won't be called in case that cleanUp throws an exception, see commentes under https://github.com/jenkinsci/jenkins/commit/51f715162eba4dd1c4e081ec15c7ceb12e813ca5