dependency graph. This functionality is enabled through a feature flag,
hudson.tasks.Fingerprinter.enableFingerprintsInDependencyGraph, which is off
by default.

- Rebuild the dependency graph as part of each fingerprint action.
  Fingerprinter.buildDependencyGraph adds information to the dependency graph
  for projects found in fingerprint records. Since the dependency graph is
  based on project, once a relationship is established between two projects,
  we can skip scanning subsequent builds of the projects. Entries in the
  graph added by the fingerprinter action will never automatically trigger
  downstream builds.

   core/src/main/java/hudson/tasks/Fingerprinter.java

- When reporting dependency changes, don't consider builds that no longer
  exist. This handles issues when projects are renamed, and new projects are
  created using the same name, causing the change to point to incorrect
  builds.

   core/src/main/java/hudson/model/AbstractBuild.java

- Tests.

   test/src/test/java/hudson/tasks/FingerprinterTest.java

Conflicts:
	core/src/main/java/hudson/LocalPluginManager.java

Max Spring discovered a stack overflow in http://jenkins.361315.n4.nabble.com/channel-example-and-plugin-classes-gives-ClassNotFoundException-td3756092.html that pointed this call into thread context classloader (TCL) as the culprit. Independently, Paul Sandoz discovered the same issue in our products. If TCL is another classloader that delegates to UberClassLoader (UCL), this code causes infinite recursion.

And moreover, given the goal of UCL, it seems wrong that this class is changing behaviour based on contextual information like TCL.

 In looking at 4de81f1e, the change was introduced to make sure XStream unmarshalling invoked from Plugin.start() would see the classes in that plugin. This was an issue back then when plugins are prepared and loaded one by one, as UCL didn't have visibility into plugins being prepared. But in the current Jenkins, classloaders for all the plugins are prepared, before any plugin gets started, so by the time Plugin.start() runs, UCL is fully functioning.

 Therefore, there's no need to consult TCL for the purpose of resolving its own classes. I could have also removed the code that sets TCL, but because some libraries often depend on TCL and doesn't properly look at caller class, I'm leaving it in, even though it's generally a bad practice to rely on TCL in multi-classloader apps like Jenkins

not exposing the setBuiltOnStr to arbitrary external methods. It's really only for internal consumption.

Remove the shadow copy of buildOn from MavenBuild.java and move the setter to
AbstractBuild to allow MavenModuleSetBuild.java to continue to set the
build node.

following up tweaks to the previous commit, and explaining what we don't do so that future versions don't inadvertently mess up them

Add displayName and description as further optional tags that can be submitted as part of an External run

Use stock gmaven plugin to achieve this

fixed serving of JARs if running with hudson-dev:run which was broken since https://github.com/jenkinsci/jenkins/commit/a376eb5832a75d4fb840a9088b37a988582b0965

Ignore null reporters field in MavenBuild$RunnerImpl.post2 and avoid a NPE.
Thanks !

The NPE can occur if a build fails during checkout and hence the run phase
never gets called. See JENKINS-10831 for an example of this happening.