This could be useful in trying to track down when things break in special
ways.

Also fixes some other cosmetic changes needed for the project rename.

Ant build step had quite a mix: buildFile and antOpts expanded against
env, properties against buildVariables, and targets against both.
Now merging buildVariables into env and applying to all.

SlaveComputer.getChannelToMaster() can be null if Launcher is used to connect other VMs than the slaves.

So act gracefully

 I added a mode where one can launch a child process without the built-in pumping support, making it trivial to read until EOF in the distributed environments.

 This concludes the fix.

from global level (not in a job config page).  Require admin permission for this.
Based on patch from bap.

as this content later gets eval'ed.  Javascript errors could occur when view names
or user names contained '

[FIXED JENKINS-7809] fixed a race condition in obtaining the tail of the output from remote process.

[FIXED JENKINS-7649] Only including one SCMTrigger.BuildAction per build, since there's only one possible polling log to link to.

differentiation between Process InputStream&ErrorStream :-(. This
means that closing errorStream will actually close every streams. 

This method is called after assinging the workspace to the build, but before SCM checkout. Can be implemented by BuildWrappers.

I did a checkout for our internal fork of JmDNS [1] and the
upstream version [2] to compare what the differences were..
I found none. There do not appear to be any local edits to
our fork so I can not figure out why we did the fork to
begin with.

Perhaps some older version had locally patched bugs which
have since been resolved? Anyhow, given that JENKINS-8647
is causing lots of people lots of grief, and it is enabled
by default, I went ahead and bumped to jmdns-3.4.0 upstream.

I think reduction of forks for library projects is generally
good, and especially when we have no practical changes made
to our version.

[1] https://github.com/jenkinsci/jmdns
[2] https://jmdns.svn.sourceforge.net/svnroot/jmdns/tags/JmDNS_3_2_1/

* rc:
  Fix dependency on Java2 runtime for both Debian and Ubuntu
  [FIXED JENKINS-4047] not admin, should be adm.
  [FIXED JENKINS-8159] back to java-runtime

In Debian, a dependency on 'java-runtime' virtual package may be
satisfied by pre-Java2 JVM [1] which is wrong. According to Debian
policy for Java [2], virtual machines that contain a runtime
conforming to the Java 2 specification should provide java2-runtime
[3] and Java programs must depend on the needed runtime environment
(java1-runtime and/or java2-runtime) [4].

As Jenkins' target is 1.5+, it's better to depend on Java2 JVM [5]
explicitly.

This should also work in Ubuntu as Sun Java5 [6],
Sun Java6 [7] and OpenJDK [8] packages provide 'java2-runtime' too.

[1] http://packages.debian.org/sid/java-runtime
[2] http://www.debian.org/doc/packaging-manuals/java-policy/
[3] http://www.debian.org/doc/packaging-manuals/java-policy/c43.html#policy-vm
[4] http://www.debian.org/doc/packaging-manuals/java-policy/x85.html
[5] http://packages.debian.org/sid/java2-runtime
[6] http://packages.ubuntu.com/hardy/sun-java5-jre
[7] http://packages.ubuntu.com/hardy/sun-java6-jre
[8] http://packages.ubuntu.com/maverick/openjdk-6-jreSigned-off-by: NMykola Nikishov <mn@mn.com.ua>