This is a proof of concept to core modulizarion (by binary integration.)
A module is built like a plugin but it's packaged to the war as a
WEB-INF/lib/*.jar, not as a plugin.

Compared to plugins, jars integrated in this way do not double-package
dependency jars, and they are not visible to the users. I plan to try a
few of these and if it's useful, this could be an useful mechanism for
modularizing core.

[FIXED JENKINS-9102] Changed buildListTable column name from Date to Time Since, to reflect actual content.

Added a configuration option to control initialization of the
environment of the Jenkins server process.

For openSUSE it doesn't make sense to require a specific flavor of JRE
for Jenkins. Even if the RPM explicitly requires the Oracle JDK, thus
causing it to be installed together with Jenkins, some previously installed
JRE may still be used to run Jenkins, due to the update-alternatives(8) setting.
The JRE to use is a sysadmin issue, and not usually part of the RPM spec.

I have not been able to reproduce the scenario described by David.
Installing Jenkins on fresh installs of openSUSE since v11.1 pulls in openJDK
1.6 with it, with which Jenkins runs just fine. Even on Live CDs.

type references by default (can now be done by passing "true" parameter).
This restores ability to use %VAR% references for ant build steps on windows.

Reverted my fix, implemented the suggested change.

as they don't change a lot build will be faster !

Initialize the environment of the Jenkins server process correctly.

http://jira.codehaus.org/browse/MCOMPILER-109

Also see http://d.hatena.ne.jp/ssogabe/20091030/1256904551#c
and http://d.hatena.ne.jp/sikakura/20110308/1299546068 --- the issue is
that it fails when built on Japanese locale.

[FIXED JENKINS-8968] When both "block build when upstream/downstream is building" are checked,the upstream block check wasn't taking effect.