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.

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.