- This is an initial version of the feature.
- The information about slave names is still exposed via label autocomplete

Suppressed a confusing 2nd error message.

[JENKINS-19192] Using JNR 3.0.1 which includes JNR-FFI 1.0.7; 1.0.6 has the backported fix for Guava #1505, the root cause.
So this upgrade ought to prevent a recurrence of the issue in case some other code refers to JNR from the CLI.
(As yet untested, and we do not especially want to send JNR over the CLI channel anyway for performance reasons.)

Running hypothesis: something historically saved a user configuration file with a bogus fullName;
thereafter anyone calling User.get(correctFullName) will get a User with the old fullName.
This would make the bug unreproducible in fresh Jenkins installations.

Use an href for external URL in @see clause

[JENKINS-18485] Enable Computer.EXTENDED_READ permission using "hudson.security.ExtendedReadPermission".

[JENKINS-18721] Imrovement of performance - now when ListView builds up it asks for all the jobs only once. This is important because RBAC plugin each time checks permissions for all these jobs which impacts performance

f:repeatableProperty documentation talks about including f:repeatableDeleteButton, but then fails to actually call d:invokeBody.
While you could put the delete button at the end of the nested config.jelly, this is ugly since it prevents reuse;
better to specify the delete button in the form using f:repeatableProperty.
f:repeatableHeteroProperty already inserted a delete button automatically, so its documentation was incorrect.

Observed in 1.509.2:
Parsing POMs
Failed to transfer Could not find artifact … in central (http://repo.maven.apache.org/maven2)
Archiving artifacts
ERROR: Processing failed due to a bug in the code. Please report this to jenkinsci-users@googlegroups.com
java.lang.NullPointerException
	at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:138)
	at org.zeroturnaround.jenkins.LiveRebelDeployBuilder.getArtificatOrMetadata(LiveRebelDeployBuilder.java:194)
	at org.zeroturnaround.jenkins.LiveRebelDeployBuilder.uploadConfiguration(LiveRebelDeployBuilder.java:171)
	at org.zeroturnaround.jenkins.LiveRebelDeployBuilder.perform(LiveRebelDeployBuilder.java:108)
	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:812)
	at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.build(MavenModuleSetBuild.java:828)
	at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:779)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:594)
	at hudson.model.Run.execute(Run.java:1575)
	at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:485)

1. Use AtomicFileWriter on the hypothesis that an exception during save() caused truncation.
2. Improve logging from the cleanup thread since that may be related to the root cause.
3. Regardless of the cause, recover more gracefully by deleting any truncated file rather than throwing the error up.