Given these <variable,value> mappings: <A,a> and <A.B,a-b>, $A.B would
evaluate to $a.B, as it currently does, and ${A.B} to a-b instead of the
current ${A.B}.

Existing ${A.B}-like references will break (not evaluate to ${A.B}) if
there actually is an A.B variable defined, which I think is very
unlikely.

[FIXED JENKINS-18813] Add/RemoveTrigger now works

See https://groups.google.com/forum/#!topic/jenkinsci-dev/CPab12692Qs
and https://github.com/jenkinsci/jenkins/pull/873 for the context.

This change reimplements nullin's original commit as it contains too
many noise changes.

Show full job names in checkbox tooltips when configuring list views

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.)

[[JENKINS-16301] Use a buffered input stream to get somewhat better performance also from Maven archiving.
Introducing Util.getDigestOf(File) as a convenience.

[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.

Ensure the addTrigger and removeTrigger methods only use methods that are
supported by DescribableList. This means no indexed operations are
supported, so use only Iterator#remove and Collection#add

Add Integration Tests to ensure methods work as expected

java.io.IOException: …/builds/2013-07-11_12-21-02 is in use
    at hudson.model.Run.delete(Run.java:1363)
    at hudson.tasks.LogRotator.perform(LogRotator.java:133)
    at hudson.model.Job.logRotate(Job.java:406)
    at hudson.model.Run.execute(Run.java:1638)

Refactor ListView to allow to set includeRegex programmatically

Merge branch 'maven-3.1.0' for maven 3.1.0 support in Maven Integration Plugin

Unclear what Run.getEnvironment is supposed to return after the build is complete.
In particular, SubversionSCM calls this during polling to substitute variables in e.g. repo URL.
Presumably in such a case node-specific variables such as ToolInstallation.home would be irrelevant.
But in general should this reflect the “current” computer (if any), or the computer on which the build ran?

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

Fix javadoc for QueueTaskDispatcher and NodeProperty

Fix javadoc for @see reference in MatrixAggregator

Fix SCMTriggerCause javadoc to deprecated constructor

Fix javadoc link in MatrixExecutionStrategy

Uses the outer class plus the inner class to name the argument, which
satisfies javadoc.

There is a BuildableItem interface in hudson.model, but the references
in these files to BuildableItem objects are refering to an inner class
of the Queue object, not to the interface defined in huson.model.  The
javadoc link improvement may help authors see that difference.

http://javadoc.jenkins-ci.org/hudson/matrix/MatrixAggregator.html#startBuild()
has an @see reference which should be a link.