The code is smart enough to compute a minimum set of builds to remove to
restore order consistency.

Also cleaning up variable names to be less misleading.

Note that new File("target") is really a bad idea since we cannot predict the CWD in effect when Maven is run.
(From the standard bin/mvn launcher, it seems that it will always be *some* Maven project at least.
This may not be true for Maven run embedded from various tools.)
But leaving that as is for now, since it is not clear how else we would find the project location.
(new File(env.description().getTestClass().getProtectionDomain().getCodeSource().getLocation().toURI()).getParentFile() might work but it is pretty hacky.)

[FIXED JENKINS-18178] Reverting an inessential part of the fix of JENKINS-16301 since it broke some Maven builds.
Apparently the Maven 2 process factory fails to adequately insulate the Maven process from Jenkins library dependencies;
if you specify a build extension that can override dependencies used by Jenkins core classes!
A real fix would involve changing class loader delegation, since presumably similar bugs could still occur.

[FIXED JENKINS-18898] ToolInstallation.getHome may be null, and buildEnvVars must take that into account.

Clearer display of log messages: chronological order, and coloration of repeated vs. fresh metadata.

Also ensuring that Jenkins configuration is saved after new XML is POSTed.

If so, retry with (6+) slave JVM, setting maven-{compiler,surefire}-plugin properties to point to original.

Integrated the fix into Jenkins

... with a test case. The fix is in Stapler.

System.nanos() returns a monotonically increasing value that is not related
to wallclock time. Use System.currentTimeMillis() instead.

Unlike the bug I originally reproduced, in which the parent had some builds
but the context in which the new build was scheduled omits a parent,
this seems to be due to a case in which there is no build record at all for the parent.
No idea how that could happen (getLastBuild should return even a running, failed, or aborted build),
but @treydock reports a stack trace in 1.509.2 which implies this.
So fixing null safety; will not prevent an exception but will report it more gracefully.

The earlier fix by @ssogabe broke the test. This fix corrects the
problem properly.

The reason this error happens with some plugins is that if there's an
input field whose name is "on", then even after prototype.js extends
an element object, "form.on" will refer to the input element, not the
prototype.js function to add an event handler.

Use DescribableList to handle the copy-on-write semantics correctly. The vector class just doesn't cut it, and we've been setting a new value to this field, which will violates all sorts of the concurrent programming practice.

This change has the nice side effect of removing {{class="vector"}} from the persisted XML. A test is added to make sure we can still read back such an XML.

Revisiting the fix. Avoid parsing the entire text by only looking at the tail portion.

Node monitoring should run in parallel to reduce the total round-trip
time in large instances.

Integrated the fix toward 1.521.