-
New Feature
-
Resolution: Fixed
-
Major
-
None
-
Platform: All, OS: All
For some purposes it is desirable to use a ToolInstallation during a build, but
not in the expected way - such as running hudson.tasks.Ant or setting a
Project.jdk. Examples from deadlock.netbeans.org:
1. You may wish to associate JDK 6 with the build, i.e. actually put jdk6/bin
into $PATH and set JAVA_HOME to jdk6, yet also compile certain sources against
JDK 5 (or run unit tests using JDK 5) to ensure compatibility. Currently you
have to hardcode the JDK 5 location, which makes tool installation useless.
2. You may wish to run a shell script which runs Ant targets or Maven goals
along with some other things, rather than using Hudson's built-in tasks for
these things. Currently you can either assume some appropriate version of 'ant'
or 'mvn' is in the server's $PATH, or hardcode locations to these tools.
Better would be a BuildWrapper which would let you configure a list of required
tools (of any type, as listed in Hudson global configuration) as well as
matching environment variable names (perhaps defaulting to the tool name plus
'_HOME'). buildEnvVars would then get these tools for the node (meaning
installing them if necessary) and set the env vars according to
ToolInstallation.home.
For example, your if your server config had an "ant171" installed from
apache.org, your project configuration might request "ant171" -> ANT_HOME, and
your build script could say
$ANT_HOME/bin/ant build
Or if your server config had "jdk5" installed from sun.com as 1.5.0_18, your
project config could have "jdk5" -> JDK5_HOME, and your build script could say
javac src/*.java -bootclasspath $JDK5_HOME/jre/lib/rt.jar
to ensure you were not using newer platform classes.
The Java part of this should be trivial to write, probably as a plugin. I have
no clue how to convince Jelly + /lib/form to display & persist an expandable
list of rows each containing a ToolInstallation.name in a dropdown next to a
textbox for the var name.