Installation

The current Gradle release is 7.0. You can download binaries and view docs for all Gradle versions from the releases page.

Prerequisites

Gradle runs on all major operating systems and requires only a Java JDK version 8 or higher to be installed. To check, run java -version :

Additional resources

• On-demand and live online training is available for free to Gradle users.
• Self-paced tutorials are a good place to try Gradle with a variety of languages in addition to the docs.
• Gradle has a new visual build inspection tool called build scans.
• Finally, the Gradle Newsletter is a great way to keep UP-TO-DATE , with issues crafted monthly.

Installing with a package manager

SDKMAN! is a tool for managing parallel versions of multiple Software Development Kits on most Unix-based systems.

Homebrew is “the missing package manager for macOS”.

Other package managers are available, but the version of Gradle distributed by them is not controlled by Gradle, Inc. Linux package managers may distribute a modified version of Gradle that is incompatible or incomplete when compared to the official version (available from SDKMAN! or below).

› Additional helpful information

Installing manually

Step 1. Download the latest Gradle distribution

The current Gradle release is version 7.0, released on 09 Apr 2021. The distribution zip file comes in two flavors:

If in doubt, choose the binary-only version and browse docs and sources online.

Need to work with an older version? See the releases page.

Step 2. Unpack the distribution

Linux & MacOS users

Unzip the distribution zip file in the directory of your choosing, e.g.:

Microsoft Windows users

Create a new directory C:\Gradle with File Explorer.

Open a second File Explorer window and go to the directory where the Gradle distribution was downloaded. Double-click the ZIP archive to expose the content. Drag the content folder gradle-7.0 to your newly created C:\Gradle folder.

Alternatively you can unpack the Gradle distribution ZIP into C:\Gradle using an archiver tool of your choice.

Step 3. Configure your system environment

Linux & MacOS users

Configure your PATH environment variable to include the bin directory of the unzipped distribution, e.g.:

Microsoft Windows users

In File Explorer right-click on the This PC (or Computer ) icon, then click Properties -> Advanced System Settings -> Environmental Variables .

Under System Variables select Path , then click Edit . Add an entry for C:\Gradle\gradle-7.0\bin . Click OK to save.

Step 4. Verify your installation

Open a console (or a Windows command prompt) and run gradle -v to run gradle and display the version, e.g.:

› Additional helpful information

Upgrade with the Gradle Wrapper

If your existing Gradle-based build uses the Gradle Wrapper, you can easily upgrade by running the wrapper task, specifying the desired Gradle version:

Note that it is not necessary for Gradle to be installed to use the Gradle wrapper. The next invocation of gradlew or gradlew.bat will download and cache the specified version of Gradle.

› Additional helpful information

Older Releases

You can find all releases and their checksums on the releases page.

Command-Line Completion

Command-line completion scripts are available for bash and zsh. This provides completion for Gradle tasks and command-line options.

Installing Gradle

You can install the Gradle build tool on Linux, macOS, or Windows. This document covers installing using a package manager like SDKMAN! or Homebrew, as well as manual installation.

Use of the Gradle Wrapper is the recommended way to upgrade Gradle.

You can find all releases and their checksums on the releases page.

Prerequisites

Gradle runs on all major operating systems and requires only a Java Development Kit version 8 or higher to run. To check, run java -version . You should see something like this:

Gradle ships with its own Groovy library, therefore Groovy does not need to be installed. Any existing Groovy installation is ignored by Gradle.

Gradle uses whatever JDK it finds in your path. Alternatively, you can set the JAVA_HOME environment variable to point to the installation directory of the desired JDK.

Installing with a package manager

SDKMAN! is a tool for managing parallel versions of multiple Software Development Kits on most Unix-like systems (macOS, Linux, Cygwin, Solaris and FreeBSD). We deploy and maintain the versions available from SDKMAN!.

Homebrew is «the missing package manager for macOS».

Other package managers are available, but the version of Gradle distributed by them is not controlled by Gradle, Inc. Linux package managers may distribute a modified version of Gradle that is incompatible or incomplete when compared to the official version (available from SDKMAN! or below).

Installing manually

Step 1. Download the latest Gradle distribution

The distribution ZIP file comes in two flavors:

Complete (all) with docs and sources

Need to work with an older version? See the releases page.

Step 2. Unpack the distribution

Linux & MacOS users

Unzip the distribution zip file in the directory of your choosing, e.g.:

Microsoft Windows users

Create a new directory C:\Gradle with File Explorer.

Open a second File Explorer window and go to the directory where the Gradle distribution was downloaded. Double-click the ZIP archive to expose the content. Drag the content folder gradle-7.0 to your newly created C:\Gradle folder.

Alternatively, you can unpack the Gradle distribution ZIP into C:\Gradle using an archiver tool of your choice.

Step 3. Configure your system environment

To run Gradle, the path to the unpacked files from the Gradle website need to be on your terminal’s path. The steps to do this are different for each operating system.

Linux & MacOS users

Configure your PATH environment variable to include the bin directory of the unzipped distribution, e.g.:

Alternatively, you could also add the environment variable GRADLE_HOME and point this to the unzipped distribution. Instead of adding a specific version of Gradle to your PATH , you can add $GRADLE_HOME/bin to your PATH . When upgrading to a different version of Gradle, just change the GRADLE_HOME environment variable.

Microsoft Windows users

In File Explorer right-click on the This PC (or Computer ) icon, then click Properties → Advanced System Settings → Environmental Variables .

Under System Variables select Path , then click Edit . Add an entry for C:\Gradle\gradle-7.0\bin . Click OK to save.

Alternatively, you could also add the environment variable GRADLE_HOME and point this to the unzipped distribution. Instead of adding a specific version of Gradle to your Path , you can add %GRADLE_HOME%/bin to your Path . When upgrading to a different version of Gradle, just change the GRADLE_HOME environment variable.

Verifying installation

Open a console (or a Windows command prompt) and run gradle -v to run gradle and display the version, e.g.:

You can verify the integrity of the Gradle distribution by downloading the SHA-256 file (available from the releases page) and following these verification instructions.

Next steps

Now that you have Gradle installed, use these resources for getting started:

Create your first Gradle project by following one of our step-by-step samples.

Sign up for a live introductory Gradle training with a core engineer.

Learn how to achieve common tasks through the command-line interface.

Configure Gradle execution, such as use of an HTTP proxy for downloading dependencies.

Subscribe to the Gradle Newsletter for monthly release and community updates.

How do I install gradle on Windows 10?

I tried some ways with the path thing, but it did not work. When I edit the path in the System variables it opens up all the paths, not like in tutorials, where I should just put the ;%GRADLE_HOME%\bin at the end.

5 Answers 5

Download Gradle and unzip it to where you want it installed.

Then in Windows Search, search for «System» and then select: System (Control Panel)

Click the Advanced system settings link.

Click Environment Variables

Then click New button under user variable and add GRADLE_HOME to variable name and path pointing to the root directory of unpacked files from the Gradle to variable value.

In System variable section select Path and then click the Edit button. In next window click New button and add path pointing to the bin directory of unpacked files from the Gradle.

If you are window user then Scoop will be the best option to installs the tools you know and love. Scoop is simply a command line installer.

simply run this command scoop install gradle

But first you need to install scoop using powershell command

Note: if you get an error you might need to change the execution policy (i.e. enable Powershell) with following command

Download Gradle and unzip it to where you want it installed. Then open your USER variables window for your user (similar to what you show) and create a GRADLE_HOME variable with a path pointing to the root directory of your downloaded Gradle distribution. Then add it to the PATH in your USER variables with something like:

Notice that I have prepended the existing PATH variable onto the new one. You don’t want to remove what’s already there. Also, your image shows something else added to the path. You will want to add that on to the line above, something like:

Шпаргалка по Gradle

Как мне кажется, большинство людей начинают разбираться с gradle только тогда, когда в проекте что-то надо добавить или что-то внезапно ломается — и после решения проблемы «нажитый непосильным трудом» опыт благополучно забывается. Причём многие примеры в интернете похожи на ускоспециализированные заклинания, не добавляющие понимания происходящего:

Я не собираюсь подробно описывать, для чего нужна каждая строчка выше — это частные детали реализации андроид-плагина. Есть кое-что более ценное — понимание того, как всё организовано. Информация раскидана по различным сайтам/официальной документации/исходникам градла и плагинов к нему — в общем, это чуть более универсальное знание, которое не хочется забывать.

Дальнейший текст можно рассматривать как шпаргалку для тех, кто только осваивает gradle или уже забыл.

Полезные ссылки

Консоль

Android studio/IDEA старательно прячет команды gradle от разработчика, а ещё при изменении build.gradle файликов начинает тупить или перезагружать проект.

В таких случаях вызывать gradle из консоли оказывается намного проще и быстрее. Враппер для gradle обычно идёт вместе с проектом и прекрасно работает в linux/macos/windows, разве что в последнем надо вызывать bat-файлик вместо враппера.

Вызов задач

пишет доступные задачи.

Можно вывести задачи отдельного подпроекта, а ещё с опцией —all будут выведены все задачи, включая второстепенные.

Можно вызвать любую задачу, при этом будут вызваны все задачи, от которых она зависит.

Если лень писать название целиком, можно выкинуть маленькие буковки:

Если градл не сможет однозначно угадать, какую именно задачу имели ввиду, то выведет список подходящих вариантов.

Логгинг

Количество выводимой в консоль информации при запуске задачи сильно зависит от уровня логгинга.
Кроме дефолтного есть -q, -w, -i, -d , ну или —quiet, —warn, —info, —debug по возрастанию количества информации. На сложных проектах вывод с -d может занимать больше мегабайта, а поэтому его лучше сразу сохранять в файл и там уже смотреть поиском по ключевым словам:

Если где-то кидается исключение, для stacktrace опция -s .

Можно и самому писать в лог:

логгер является имплементацией SLF4J.

Groovy

Происходящее в build.gradle файликах — просто код на groovy.

Groovy как язык программирования почему-то не очень популярен, хотя, как мне кажется, он сам по себе достоин хотя бы небольшого изучения. Язык появился на свет ещё в 2003 году и потихоньку развивался. Интересные особенности:

• Практически любой java код является валидным кодом на groovy. Это очень помогает интуитивно писать работающий код.
• Одновременно вместе со статической, в груви поддерживается динамическая типизация, вместо String a = «a» можно смело писать def a = «a» или даже def map = [‘one’:1, ‘two’:2, ‘list’ = [1,false]]
• Есть замыкания, для которых можно динамически определить контекст исполнения. Те самые блоки android <. >принимают замыкания и потом исполняют их для какого-то объекта.
• Есть интерполяция строк «$a, $» , multiline-строки «»»yep, $«»» , а обычные java-строки обрамляются одинарными кавычками: ‘text’
• Есть подобие extension-методов. В стандартной коллекции языка уже есть методы типа any, every, each, findAll. Лично мне названия методов кажутся непривычными, но главное что они есть.
• Вкусный синтаксический сахар, код становится намного короче и проще. Можно не писать скобки вокруг аргументов функции, для объявления списков и хеш-табличек приятный синтаксис: [a,b,c], Run gradle on windows

В общем, почему языки типа Python/Javascript взлетели, а Groovy нет — для меня загадка. Для своего времени, когда в java даже лямбд не было, а альтернативы типа kotlin/scala только-только появлялись или ещё не существовали, Groovy должен был выглядеть реально интересным языком.

Именно гибкость синтаксиса groovy и динамическая типизация позволила в gradle создавать лаконичные DSL.

Сейчас в официальной документации Gradle примеры продублированы на Kotlin, и вроде как планируется переходить на него, но код уже не выглядит таким простым и становится больше похожим на обычный код:

Впрочем, переименование в Kradle пока не планируется.

Стадии сборки

Их делят на инициализацию, конфигурацию и выполнение.

Идея состоит в том, что gradle собирает ациклический граф зависимостей и вызывает только необходимый минимум их них. Если я правильно понял, стадия инициализации происходит в тот момент, когда исполняется код из build.gradle.

Возможно, это неочевидно, но вышеуказанное будет тормозить инициализацию. Чтобы не заниматься копированием файлов при каждой инициализации, нужно в задаче использоваль блок doLast <. >или doFirst <. >— тогда код завернётся в замыкание и его позовут в момент выполнения задачи.

В старых примерах вместо doLast можно встретить оператор , но от него потом отказались из-за неочевидности поведения.

tasks.all

Что забавно, с помощью doLast и doFirst можно навешивать какие-то действия на любые задачи:

IDE подсказывает, что у tasks есть метод whenTaskAdded(Closure . ) , но метод all(Closure . ) работает намного интереснее — замыкание вызывается для всех существующих задач, а так же на новых задачах при их добавлении.

Создадим задачу, которая распечатает зависимости всех задач:

Если tasks.all<> вызвать во время выполнения (в блоке doLast ), то мы увидим все задачи и зависимости.
Если сделать то же самое без doLast (т.е., во время инициализации), то у распечатанных задач может не хватать зависимостей, так как они ещё не были добавлены.

Ах да, зависимости! Если другая задача должна зависеть от результатов выполнения нашей, то стоит добавить зависимость:

inputs, outputs и инкрементальная сборка

Обычная задача будет вызываться каждый раз. Если указать, что задача на основе файла А генерирует файл Б, то gradle будет пропускать задачу, если эти файлы не изменились. Причём gradle проверяет не дату изменения файла, а именно его содержимое.

Аналогично можно указать папки, а так же какие-то значения: inputs.property(name, value) .

task description

При вызове ./gradlew tasks —all стандартные задачи имеют красивое описание и как-то сгруппированы. Для своих задач это добавляется очень просто:

task.enabled

можно «выключить» задачу — тогда её зависимости будут всё равно вызваны, а она сама — нет.

несколько проектов (модулей)

В основном проекте можно расположить ещё несколько модулей. Например, такое используется в андроид проектах — в рутовом проекте почти ничего нет, в подпроекте включается android плагин. Если захочется добавить новый модуль — можно добавить ещё один, и там, например, тоже подключить android плагин, но использовать другие настройки для него.

Ещё пример: при публикации проекта с помощью jitpack в рутовом проекте описывается, с какими настройками публиковать дочерний модуль, который про факт публикации может даже не подозревать.

Дочерние модули указываются в settings.gradle:

Подробнее про зависимости между проектами можно почитать здесь

buildSrc

Если кода в build.gradle много или он дублируется, его можно вынести в отдельный модуль. Нужна папка с магическим именем buildSrc , в которой можно расположить код на groovy или java. (ну, вернее, в buildSrc/src/main/java/com/smth/ код, тесты можно добавить в buildSrc/src/test ). Если хочется что-то ещё, например, написать свою задачу на scala или использовать какие-то зависимости, то прямо в buildSrc надо создать build.gradle и в нём указать нужные зависимости/включить плагины.

К сожалению, с проектом в buildSrc IDE может тупить c подсказками, там придётся писать импорты и классы/задачи оттуда в обычный build.gradle тоже придётся импортировать. Написать import com.smth.Taskname — не сложно, просто надо это помнить и не ломать голову, почему задача из buildSrc не найдена).

По этой причине удобно сначала написать что-то работающее прямо в build.gradle , и только потом переносить код в buildSrc .

Свой тип задачи

Задача наследуется от DefaultTask , в которой есть много-много полей, методов и прочего. Код AbstractTask, от которой унаследована DefaultTask.

• вместо ручного добавления inputs и outputs можно использовать поля и аннотации к ним: @Input, @OutputFile и т.п.
• метод, который будут запускать при выполнении задачи: @TaskAction .
• удобные методы типа copy всё ещё можно вызвать, но придётся их явно вызывать для проекта: project.copy

Когда для нашей задачи кто-то в build.gradle пишет

у задачи вызывается метод configure(Closure) .

Я не уверен, что это правильных подход, но если у задачи есть несколько полей, взаимное состояние которых сложно контролировать геттерами-сеттерами, то кажется вполне удобным переопределить метод следующим образом:

Причём даже если написать

то метод configure всё равно будет вызван.

Свой плагин

Подобно задаче, можно написать свой плагин, который будет что-то настраивать или создавать задачи. Например, происходящее в android <. >— полностью заслуга тёмной магии андроид плагина, который вдобавок создаёт целую кучу задач типа app:assembleDevelopDebug на все возможные сочетания flavor/build type/dimenstion. Ничего сложного в написании своего плагина нет, для лучшего понимания можно посмотреть код других плагинов.

Есть ещё третья ступенька — можно код расположить не в buildSrc , а сделать его отдельным проектом. Потом с помощью https://jitpack.io или ещё чего-то опубликовать плагин и подключать его аналогично остальным.

The end

В примерах выше могут быть опечатки и неточности. Пишите в личку или отмечайте с ctrl+enter — исправлю. Конкретные примеры лучше брать из документации, а на эту статью смотреть как на списочек того «как можно делать».