IntelliJ IDEA's popular build tool - Gradle

IntelliJ IDEA is an integrated environment for java programming language development. IntelliJ is recognized as the best java development tool in the industry, especially in intelligent code assistant, automatic code prompt, refactoring, JavaEE support, various version tools (git, svn, etc.), JUnit, CVS integration, code analysis, innovative The functions such as GUI design can be said to be extraordinary.

Nowadays, building tools are an important part of all projects, and IntelliJ IDEA has been integrated with most building tools. The current popular building tool is Gradle. In this article, we briefly describe the history of its integration with IntelliJ IDEA and the delegation process implemented within the IDE.

IntelliJ IDEA v2023.1 official version download

starting point

IntelliJ IDEA has been on the market longer than any other build tool and has offered its native build system for many years with great success. The IntelliJ IDEA build system is always the best choice for tasks like compiling, running tests, and packaging into JARs.

Developers are often primarily concerned with compiling and running tests, so a fast feedback cycle for the build process is critical, whereas we specialize in executing JUnit and TestNG tests and incremental compilation.

Before Gradle

Maven came out with great project dependency management capabilities, and we leveraged its project structure and delegated downloading and resolving dependencies to Maven (but left the build process to IntelliJ IDEA).

We were able to replicate Maven's build process in the IntelliJ IDEA build system. Based on the Maven project model, IntelliJ IDEA can build projects with minimal extra steps. At the same time, we have developed a mechanism for efficiently retrieving resource processing information, covering the generation of MANIFEST.mf files from pom.xml, and further enhancing the build process.

We then apply the results of the build process to the native process that executes the tests.

With this improvement, we were able to cover all the necessary scenarios for successfully building a Maven project with IntelliJ IDEA.

Continue to use this setup for Maven projects: Retrieve necessary information from Maven, build and start projects using native IntelliJ IDEA mechanisms, even for popular tools like Spring Boot and Micronaut.

Integrate Gradle

When Gradle was launched in the market, it gave users the ability to better customize the build process and add more functionality to it.

When the decision was made to start doing something similar to Maven, it meant letting Gradle handle dependencies and retrieve the necessary information, while IntelliJ IDEA would compile the code, run the tests, and build the project.

However, the Gradle project model seems a little too flexible, you can use different source sets or languages ​​in the build script, such as Groovy, Scala or Kotlin. Alternatively, imperative code can be written in build scripts to provide direct instructions to the build system for desired behavior and settings.

For example, the database can be started before the run or before the test run. In addition, compared to Maven, which contains static configuration, Gradle build scripts allow arbitrary code execution during resource processing. It is difficult to reproduce such configurations using IntelliJ IDEA  features .

Clearly great at standard operations, but custom operations, such as handling resources and other custom tasks, were rather difficult for us to control, maintain, and most importantly replicate in the IntelliJ IDEA build system.

Therefore, we decided to delegate the test running to Gradle:

When you run tests, the Gradle test task is executed along with other tasks that are part of the Gradle build cycle, as follows:

In addition, IntelliJ IDEA also provides additional features, for example, the tests you need to run may be distributed in different source sets. Integration tests are in one source set and functional tests are in another.

IntelliJ IDEA can correctly determine the test task and its location for a specific test file, ensuring that the relevant tests are executed effectively.

In addition, IntelliJ IDEA also provides information on the test execution level - method, class or package, for example, Gradle executes all tests in the source set by default.

But IntelliJ IDEA applies the filter mode and displays a message in the Run tool window telling you exactly where the test was executed:

Overall, Gradle's test delegate is quite successful.

The next natural step is to delegate Build and Run operations to Gradle as well, and eventually delegation becomes the default choice.

Now, when the Run action is used in the application  , it is used in the Gradle context and done dynamically.

Similar to the existing Gradle application plugin, we are creating a JavaExec type task that runs the main class, which ensures maximum correctness of the application run configuration.

When Build is triggered in delegate mode, IntelliJ IDEA will generate a list of commands to be executed in Gradle according to the modified modules in the project, and you can view this information in BuildOutput:

IntelliJ IDEA can also detect files modified in different modules and build only the modified parts.

Currently, there are two delegation modes to choose from: Gradle and IntelliJ IDEA.

• Gradle : While the process is delegated to Gradle, it is slightly slower than our native build system and has a small overhead. Sometimes, in delegated mode, the Gradle daemon needs to be re-run.
  Additionally, Gradle preserves its lifecycle processes, reruns Gradle models and checks build scripts and their filesystem even if there is code compiled by IntelliJ IDEA.
• IntelliJ IDEA : If you don't have complicated settings in your Gradle project, you can use IntelliJ IDEA to speed up the build process.

Note also that annotation processing is supported in the compilation flow, but when the code is compiled by IntelliJ IDEA  , there are some edge cases that are difficult to handle, such as the case where the annotation processor is defined in a Gradle subproject.

That's the stage we're at right now, still trying to run Spring and Micronaut run configurations in delegate mode, and continuing to improve the Gradle delegation process in the IDE.