Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

As you can see in Ant, Maven, JDK, and so on, Jenkins has an ability to automate tool installation necessary for builds. This page discusses how a plugin developer can add this to their own plugin, by using Gradle as an example.

Write a crawler

The first piece you need is a crawler, which generates metadata that in turn tells Jenkins where to download the tools from. The goal is to produce a JSONP file that looks like this:

downloadService.post('hudson.plugins.gradle.GradleInstaller',{"list": [
    "id": "1.0-milestone-1",
    "name": "Gradle 1.0-milestone-1",
    "url": "http://repo.gradle.org/gradle/distributions/gradle-1.0-milestone-1-bin.zip"
    "id": "0.9.2",
    "name": "Gradle 0.9.2",
    "url": "http://repo.gradle.org/gradle/distributions/gradle-0.9.2-bin.zip"

More about the structure of the JSON file. The first "hudson.plugins.gradle.GradleInstaller" portion is the fully-qualified class name that you'll be writing later. Then a list of tuples follow, where each tuple contains an unique ID, a human readable display name, and URL to download a zip file from. The list should be sorted so that newer ones appear first. This is the order users will see in their drop-down combobox.

The crawler is a program that generates this file. It can be any program, but this is the crawler that produces the above JSONP, written in Groovy. Once you are ready with this, you can run this at your own machine or we can run it for you on our CI infrastructure. Please drop us a note at the dev list so that we can discuss.

Write an installer

Next, you write a new extension point implementation for the installer. This code tells Jenkins that you have an auto-installer for this tool. Gradle follows the standard file structure, so there's really no need to override any behaviour of the installer.

Every time the administrator sets up a new Gradle installation, a new GradleInstaller instance will created and it gets the ID that you set in the metadata JSON file above. The isApplicable method is saying that this installer can only apply to GradleInstallation. That is, using this installer for Ant doesn't make sense.

public class GradleInstaller extends DownloadFromUrlInstaller {
    public GradleInstaller(String id) {

    public static final class DescriptorImpl extends DownloadFromUrlInstaller.DescriptorImpl<GradleInstaller> {
        public String getDisplayName() {
            return "Install from Gradle.org";

        public boolean isApplicable(Class<? extends ToolInstallation> toolType) {
            return toolType==GradleInstallation.class;

Make Auto-installer a default option

You can make the auto-installer selected by default when the user adds a new tool installation. This is desirable since there's really no reason our users run around and install their own tools. To do so, add the getDefaultInstallers method to your ToolInstallation's descriptor, like this:

public class GradleInstallation extends ToolInstallation {

    public static class DescriptorImpl extends ToolDescriptor<GradleInstallation> {

        public List<? extends ToolInstaller> getDefaultInstallers() {
            return Collections.singletonList(new GradleInstaller(null));


That's it. It wasn't that hard, was it.

More complex installation scenarios

What's discussed in this page takes advantages of the stock implementation in Jenkins that's suitable for simple tool installations that only involves unzipping a zip file. If your tool installation scenario is more complex, you can still do that by extending from ToolInstaller directly instead of DownloadFromUrlInstaller. See the JDKInstaller class in the core as the starting point. It involves going through the gated download link via page scraping, choosing the right bundle based on the platform, and then installing a tool by executing an installer.

  • No labels


  1. Unknown User (whitey04)

    Is there a working example for this?  I don't think this can be followed without detailed knowledge of plugin writing and jenkins core code.

  2. Unknown User (jdamick)

    This thread helped fill in some missing pieces for me: https://groups.google.com/forum/#\!topic/jenkinsci-dev/ZQ87exrhvVA

  3. Unknown User (pablaasmo)

    The link above says:

    1. convert generated JSONP file to JSON
    2. put ${JENKINS_HOME}/updates/${installer-fqcn}

    when I want my own update file.

    But how can I easily install that file into the updates folder from a Continuous Delivery point of view?
    Is there a REST API that I can use, or do I need to do scp into the running server?

    Also if I understand it correctly, I can not tell my plugin to pick up the JSONP file from a custom URL location?
    Due to security reasons?