This is expected to improve the burst data transfer performance.

Narrowing it down to reduce the harm.

... so that we can expose them as an object that keeps track of
execution-scoped objects.

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

Integrated a new version of Stapler that provides debug logging for the
problem. See the ticket for more details of how to enable this probe.

Update Spanish

Further reduce the scope of the lock to only cover jobNames access, which is mandatory. if ig.doCreateItem requires synchronization, that's a job of ig.doCreateItem implementation, not that of ListView.

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.

Plexus compiler 1.8.6 that maven-compiler-plugin 2.4 has a static field
to store a reference to the Javac class in tools.jar

In JDK that I use (6u26), Javac has a static field that stores what
appears to be a cache of jar files (ZipFileIndex.zipFileIndexCache).
And in addition, Maven instantiates a separate ClassRealm to host plugin
jar files when a project has any build extensions.

The combined result is that during a build, we end up having multiple
copies of URLClassLoader that loads tools.jar, and each ends up caching
jar files it was used. This puts a pressure to permgen (although I
couldn't pinpoint which portions of those caches use permgen), resulting
in OOME.

In Plexus compiler 1.9, Olivier added a new feature to control the
caching/reuse of Javac compiler. While this apparently was done
primarily for fixing concurrency issues in multi-threaded builds, it is
also a useful mechanism to prevent the retention of Javac classes.

So I pushed the SNAPSHOT version of maven-compiler-plugin as
2.5-jenkins-1 and tweaking POM to use it.

Fixed grammatical error in build page message.
Thnaks!

In the end, proper fix requires having a filter that tracks
GZipOutputStream.

Until now, Jenkins.overallNodeProvisioner was tracking an inconsistent
pair of numbers. On one hand, it was tracking all the executors in the
system, but then it was also only tracking the # of free-roaming
label-unassigned jobs as the queue length.

So if all your slaves are set with Node.Mode.EXCLUSIVE and you have some
free-roaming jobs, then it'll never tickle NodePrivisioner.

In other words, the # of executors weren't reflecting the actual # of
executors that can execute what's counted as the queue length.

See the problem report at
https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-dev/bUwGEgOwv4Q

To fix this, I introduced another LoadStatistics that only counts
the # of executors that can execute free-roaming jobs, and # of
free-roaming jobs as the queue length. In this way, two pairs of numbers
are consistent.

This now allows us to use overallLoadStatistics for really the entire
system, including all executors and the total queue length. This is
primarily for administrators to see the resource utilization, and it is
not useful for NodeProvisioner input because it's mixing too many
different things.

The semantics change in OverallLoadStatistics.queueLength allows us to
deprecate its totalQueueLength field.

Fall back in non-JNA case wasn't working.

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

Backward compatibility is preventing the View.READ permission to apply
correctly. It actually overrides the View.READ instead of complementing
it.

This change only applies default READ right if the View.READ is not
available, and the user has View.CONFIGURE + the view is not empty.

See https://github.com/jenkinsci/jenkins/pull/474 for the original conversation