rather than globally configuring tools; it would be nice if a workflow could define the exact versions of tools it requires and cause them to be installed on the fly. So rather than using the globally installed tool IDs it might be nice to have something like:

withTool('maven', '3.2.2') {
  sh 'mvn package'
}

then if version 3.2.2 is not installed yet, it would cause that version of maven to be installed.

The DSL would then need to know how to install a specific version of common tools like maven / gradle etc. (e.g. using a template blob of XML which is parameterised by the version requested).

This would allow the workflow scripts to be in charge of what versions of tools they need; and not require global installations to be setup first. Kinda microservicey way of defining tools

jstrachan yes it could perhaps encode a ToolInstaller, but if this is your goal then (at least for Linux builds) you are better off just using the CloudBees Docker Workflow plugin, which lets you define the complete build environment as part of your script.

Thanks and totally agreed - I'd prefer Docker Workflow!

Its mostly the complexity of getting Docker Workflow working nicely in Kubernetes (see JENKINS-29342) that prompted me to go down the withTool hack

better yet would be if the tool step would simply add the correct directory to the platforms path variable inside the node it is called. This would also benefit https://issues.jenkins-ci.org/browse/JENKINS-30372

The behavior of the existing tool step will not be changed. New steps (or step options) may be added. Anyway modifying the global env.PATH is a poor idea since it does not work for scripts doing multiple things concurrently on different nodes.

Agreed. There's real value in tool just installing the tool - in case you've got multiple versions of a tool used in the same workflow/node.