Integrated the new version of Stapler that includes the fix.

[FIXED JENKINS-16474] Winstone and executable WAR upgraded to actually support --httpKeepAliveTimeout.

(03:21:10 PM) m2spring: kohsuke: BTW, what do you think about this Jira? https://issues.jenkins-ci.org/browse/JENKINS-16830
(03:21:13 PM) jenkins-admin: JENKINS-16830:RunnerAbortedException no longer workin in RunListener.onStartup() (Resolved) http://jenkins-ci.org/issue/16830
(03:23:01 PM) m2spring: kohsuke: The question is whether RunListener.onStart() is intended to be allowed to abort a build by throwing Run.RunnerAbortedException, or not.
(03:23:18 PM) kohsuke: still reading
(03:25:27 PM) kohsuke: m2spring: I can make it work for you
(03:25:42 PM) kohsuke: I guess you want RunnerAbortedException to be a pass-through, right?
(03:25:50 PM) m2spring: I'm using now RunListener.setupEnvironment().
(03:25:58 PM) m2spring: This works and makes also a lot of sense.
(03:26:36 PM) m2spring: I can also see that not allowing onStart() to abort a build can make sense.
(03:26:51 PM) m2spring: I just wanted to hear your take on this.
(03:27:05 PM) kohsuke: kutzi is right that onStart() wasn't really intended to affect the build
(03:27:15 PM) kohsuke: it really was meant for just notifying
(03:27:33 PM) m2spring: Thanks for the clarification.
(03:27:40 PM) kohsuke: but if this is important for someone, I'm OK with making it work.
(03:27:53 PM) kohsuke: In this case it sounds like you are OK with the current state, so I'll leave it as WONTFIX
(03:27:58 PM) m2spring: setupEnvironment() seems to be the right place.
(03:28:05 PM) m2spring: Yes. Thanks :-)
(03:28:18 PM) kohsuke: I'll mention that in setupEnvironment javadoc so that we know it's a committed semantics
(03:28:28 PM) m2spring: Agreed.

See 010b47d7307a11f0750fc01a00d99b96bbab9234 in stapler/stapler for the
actual fix.

I first discovered this on my local desktop yesterday as I was verifying
the fix for json-lib 2.4. From what I can tell, this has been broken all
along and it was working only because Facets are discovered in the lucky
order; JellyFacet got a chance to get at it before GroovyFacet did.

When I rebuilt from clean the problem stopped appearing, so I assumed
that there are some factors that cause JellyFacet to get loaded before
GroovyFacet (maybe the order in which Maven iterates dependencies or
something like that.)

But I'm no longer so sure now that I know J-on-J saw this problem at
about the same time. That's just too many coincidences.

But let's see if this would make J-on-J happy.

Due to a confusion between 0 and -1. Easier and clearer to use 0 as the “uninitialized” value.

Introduce jenkins.slaves.WorkspaceLocator
Thanks !

These are one time URLs, and this change aligns them from other /static/
links that serve 365 days expiration period.

I had to tweak UpdateSite code because JSONObject.fromObject(String)
became more strict and no longer allows extra garbage after the closing
'}'

Refine sentences.

[FIXED JENKINS-17087] getSortedDescriptorsForGlobalConfigUnclassified needed to avoid clobbering GlobalCrumbIssuerConfiguration in Jenkins.doConfigSubmit.

(Ah, the joys of dynamic typing!)

Mar 4, 2013 10:55:46 PM hudson.UDPBroadcastThread run
WARNING: UDP handling problem
java.io.IOException: Operation not permitted
	at java.net.PlainDatagramSocketImpl.send(Native Method)
	at java.net.DatagramSocket.send(DatagramSocket.java:625)
	at hudson.UDPBroadcastThread.run(UDPBroadcastThread.java:98)
→
java.net.SocketTimeoutException: Receive timed out
	at java.net.PlainDatagramSocketImpl.receive0(Native Method)
	at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:145)
	at java.net.DatagramSocket.receive(DatagramSocket.java:725)
	at hudson.UDPBroadcastThreadTest.receiveAndVerify(UDPBroadcastThreadTest.java:70)
	at hudson.UDPBroadcastThreadTest.testMulticast(UDPBroadcastThreadTest.java:51)

Update translation.

Conflicts:
	plugins/pom.xml