Introduced AbstractProject.supportsMakeDisabled rather than using trick of checking for parent instanceof Jenkins.
Extracted common GUI into makeDisabled.jelly, with accompanying I18N refactoring.
Also moved all this into AbstractProject, where the relevant methods are defined, rather than Job where they are not.

One of the problems with the current way Jenkins puts JavaScripts is that most everything is in a single file. It doesn't highlight the relationship between those fragments and their corresponding tag files.

So I'm experimenting with moving out these fragments into individual JavaScript files co-located with the tag file. They then get loaded into the page via <st:adjunct>. Each script is served with unique URL such that the browser will not even have to try conditional GET when loading different pages, so this should prevent the performance problem caused by the fact that there are now lots of <script> tags in the page.

 If for some reason even this turns out to be a problem, we can always add additional build steps to concatenate them all.

reapplied the correct fix.

This reverts commit ee645202.
It appears that the author edited this file with UTF-8 encoding when
this file is actually iso-8859-1 encoded

This makes it consistent with other buttons like repeatable-add-button, and use of '-' prevents name collisions with form names, and make all of those UI controls addressible in the same namespace

[FIXED JENKINS-13695]

This reverts commit e2303ef4.

[FIXED JENKINS-13695]

The proposed fix https://github.com/buckett/jenkins/commit/eec16f1b6156aea76bd0cc6e0262538713ebffb6 has a problem in that it'd allow anything that has the given URL name as a prefix.

When managing instances with lots of jobs, the size of the view
configuration screen becomes huge because there is one line per job on
the instance.

Adding a test and fixed a broken databinding (because of SCM vs Scm)

Add PluginManager.CONFIGURE_UPDATECENTER permission which allows a user to configure update sites and proxy info.

The actual release needs to happen in a lock step, as the new plugin
needs to require yet-to-be-released version of the core. So for the time
being it's a snapshot dependency, deployed in the snapshot repository.

Previously, the presence of the xpath parameter suppressed the tree
parameter processing. This change fixes that so that the tree parameter
can be used for building small DOM, then XPath to manipulate the data
further.

... not from user's point of view, but more from implementation point of
view (and this can be used to push SCM retry counts out of the core.)

To avoid cluttering the UI unnecessarily, adding isApplicable() to
SCMCheckoutStrategyDescriptor so that it can nominate itself only for
matrix projects.

For example, a common use cases are:

- skip the parent checkout and only do the checkout in MatrixRun
- check out only once in MatrixBuild and then let all MatrixRuns build from the same directory

Accoringly,

- renamed classes to drop 'Run' since now they cover 'Build' as well.
- instead of using the boolean return value to indicate the fallback to
  default, using some backdoor to have the default implementation do
  this. I think this keeps the abstraction cleaner for the implementor
  of the extension point.

It uses Diffie Hellman to come up with one-time session key, then have
the server sign this session key to allow the client to verify that
there's no man in the middle.

404 for nearby configuration builds can make the life of automated
client script more complicated, so opt for redirection.