Report 100 recent builds in the JSON API, including in-progress builds.

Not reporting all the builds since this would nullify the lazy loading
effect. Will introduce a pagenation API that supports retrieval.

[JENKINS-15533] testing if the lazy loading can gracefully tolerate a RuntimeException during unmarshalling.

At least in the current version this working as expected

The actual fix was in the pull request #675.

- ID_FORMATTER is time zone sensitive, so comparing against # of
  milliseconds since the epoch won't be portable.

- resolveSymlink can return a relative path.

Based on comments from Jesse, revising the fix.

I'm now putting permlinks inside the builds/ directory to avoid the computing hassle involved in the split $JENKINS_HOME.

What we historically had in $JENKINS_HOME/jobs/JOB/lastSuccessfulBuild is also now subsumed by this feature. I initially attempted to create these permalinks in the buidl root directory, but turns out those symlinks aren't the same name as the ID of permalinks, so it doesn't mesh well.

And finally, a test!

Remember the permalink target as symlink (or simple text file) so that
looking that up doesn't cause the walk of the build history.
I think this is more in line with our general preference of making
$JENKINS_HOME useful (than trying to persist cache into a blackbox.)

Having a general purpose in-memory cache could be useful, so I'll see if
I can add that, too, in a way that allows someone to plug different
backend.

[FIXED JENKINS-15796] NoClassDefFoundError: 'Could not initialize class org.jvnet.hudson.Windows$MEMORYSTATUSEX' from SwapSpaceMonitor.
Not fixing actual linkage error—JNA issue of some kind—but ensuring that Jenkins reports it only once.

Setting project.build.sourceEncoding=UTF-8 so that future generations of plugin authors will not get a warning from Maven.
(And so that source files can safely use Unicode!)
Also removing the defaultGoal=package declaration; the only purpose of building this module is to install it.

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.