Webinar Recording: Composite Builds with Gradle and IntelliJ IDEA 2017.1

Trisha Gee

One of the new features in IntelliJ IDEA 2017.1 is full support for Gradle Composite Builds. We were fortunate to have Stefan Oehme from Gradle presenting a webinar, showing what composite builds are, how they work and why you might want to use them. In the second part of the webinar, I (Trisha Gee) cover the support for Gradle composite builds in IntelliJ IDEA 2017.1. Take a look at the end of this post for the full video and list of points covered with links to each section.

Support for composite builds was first introduced in IntelliJ IDEA 2016.3, with this you had the ability to add additional Gradle builds to your project, and configure them as a dependency for your composite build.  You can see this functionality at the start of the section showing the IntelliJ IDEA features, but let’s take a quick refresher course in what Gradle Composite Builds are.

Imagine you have a project set up to be dependent upon some libraries

You may have access to the source code for this library, and even be able to make changes and commit them, but this traditionally required you to use a different IntelliJ IDEA project to make the changes, then build it and somehow deploy the updated library.  But now with Gradle’s Composite Builds, you can easily update and test the library code.  All you need to do is to change settings.gradle to include the location of the build for the library code.

Now Gradle is using composite builds, i.e. it can build multiple independent projects together. IntelliJ IDEA recognises this, and as you can see from the screenshot above, it not only updates the Gradle window to reflect the multiple builds, but imports the code for the included build as an additional IntelliJ IDEA module.

Stefan talked about the use cases that really benefit from using Gradle’s composite builds. Composite build support in IntelliJ IDEA means you can work very naturally with code from other libraries, modules or plugins you may be dependent upon.  You can make changes to the library code, and even commit these changes to the library’s own repository.

If your projects are already using composite builds, IntelliJ IDEA has full support for importing, building and running these projects.  The behaviour inside the IDE is what you would expect, you get the included Gradle builds imported as IntelliJ IDEA modules.

For example, if you import a Gradle project that depends on included builds (like the one defined in the composite folder in this sample), the Gradle included builds will be identified and imported as IntelliJ IDEA modules, so you can work with all of the code that makes up the composite build, as if it were a single project.

Another use case for composite builds is to bundle together projects, possibly from different repositories, that are effectively separate modules that work together.  This use case may be particularly useful if your team is moving from a single repo "monolith" type of application to something that’s made up of independent modules or services. Gradle lets you include the builds for all the different modules (see the settings.gradle in this sample code for an example) into a composite build, and IntelliJ IDEA will find all those Gradle projects and treat them as IntelliJ IDEA modules.

The final example shown in the webinar is how valuable composite builds can be for Gradle plugin developers. Whether you’re developing a plugin and have an example project that uses the plugin to test it, or whether you’re working on an application that uses a plugin that you may want to experiment with, you can create a project from the "consumer" of the plugin (like in this sample code) and see the plugin code also imported as an IntelliJ IDEA module.

In summary, you’ll see that if you’re using composite builds with Gradle, IntelliJ IDEA will figure out the right project and module structure for you to be able to work naturally with the builds you’ve included, with the ability to see the code for the included projects, navigate to it, use refactoring and everything else works as if you were working with an ordinary IntelliJ IDEA module.

See the webinar in its full glory here.

• The use case for composite builds
• What is a composite build?
• Command line demo: Application with dependency on libraries user case
• Command line demo: Setting up a composite build with settings.gradle
• Command line demo: A composite project
• Command line demo: Plugin development use case
• Command line demo: Mono repo to multi repo use case
• Command line demo: CI use case
• Limitations of Composite Builds
• IntelliJ IDEA demo: Application with dependency on libraries use case
• IntelliJ IDEA demo: A composite project
• IntelliJ IDEA demo: Mono repo use case
• IntelliJ IDEA demo: Plugin development use case
• Questions

Subscribe to IntelliJ IDEA Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!