scm_issue_link commented on HUDSON-4532:
Code changed in hudson
User: : jglick
[FIXED HUDSON-4532] Ability to use tools in ad-hoc fashion.
> Ability to use tools in ad-hoc fashion
> Key: HUDSON-4532
> URL: http://issues.hudson-ci.org/browse/HUDSON-4532 > Project: Hudson
> Issue Type: New Feature
> Components: core
> Affects Versions: current
> Environment: Platform: All, OS: All
> Reporter: jglick
> 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
> 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.