IntelliJ IDEA 2016.3 EAP: Gradle Composite Builds and Android Studio 2.2

Posted on by Andrey Cheptsov

Fresh IntelliJ IDEA 2016.3 EAP build, packed with various improvements is here.

This and all future builds will have the Gradle composite builds support, so you can substitute any of your project dependencies with another project.

Imagine your project has compilation time dependencies to org.sample:number-utils and org.sample:string-utils:

Now, you’d like to change something in these libraries (a very common case). Normally you’d need to open the sources of these libraries as separate projects, make the changes, build, upload new artifacts to the repository, then update the dependencies in your project and only after that, verify if the changes worked ok. Another change? Rinse, repeat.

With composite builds, everything is much, much simpler. All you have to is to attach the Gradle projects of these libraries via the Add button in the Gradle tool window (my-utils in our case), and then select Compose Build Configuration from the context menu for the original project.

Then, refresh your Gradle project, and you’re all set. Now you can make any changes to the attached projects and immediately get feedback—IntelliJ IDEA will use module dependencies instead of binary ones.

Note, this feature requires Gradle 3.1 or higher. Composite builds work nicely with the option that delegates the IDE build and run actions to Gradle:

We hope this will make your life a tad easier. If you’re using Maven, don’t worry: adding a similar feature for Maven is on our roadmap.

Also, in this build we have features coming from Android Studio 2.2:

  • The Blueprint mode in the Designer that hides all of the visuals from views and shows only their outlines. You can choose to have it side by side with the Designer.
  • Constraint Layout, a new layout manager which allows to create large and complex layouts with a flat view hierarchy. It’s similar to Relative Layout in that all views are laid out according to relationships between sibling views and the parent layout, but it’s more flexible and easier to use.
  • Many stability and reliability improvements to Instant Run. If you have previously disabled Instant Run, the Android team encourages you to re-enable it. Let us know if you come across further issues.

And among other news:

  • Filter values in the Log viewer for Git and Mercurial are now persisted between IDE restarts.
  • Support for SVN 1.8’s automatic reintegration merge.

That’s it for now. Download the EAP build, give it a spin, and share your feedback via our issue tracker.

UPDATE: Code Sample Browser and Espresso Test Recorder are removed from the post as they haven’t been merged yet from Android Studio. This work is still in progress.

Develop with Pleasure!

Comments below can no longer be edited.

42 Responses to IntelliJ IDEA 2016.3 EAP: Gradle Composite Builds and Android Studio 2.2

  1. Xenophon says:

    October 13, 2016

    New Icons? Cool! But what about retrograde users?

    • Konstantin Bulenkov says:

      October 14, 2016

      Hello Xenophon.
      For retrograde users we have something like this https://plugins.jetbrains.com/plugin/7285 But I wouldn’t call a person who uses IntelliJ IDEA EAP a retrograde user 😉

      • Mikhail Kholodkov says:

        October 20, 2016

        The new icons are just worse than ever, as per my humble opinion. I can’t find any good reason to replace the old ones. What was the intention? Follow the mainstream minimalism standards? Ugh.

        Anyway, it would be nice if you can create another plugin for “retrograde” users with Intellij IDEa 2016.2 icons.

        Thanks in advance.

  2. .we says:

    October 13, 2016

    ” If you’re using Maven, don’t worry: adding a similar feature for Maven is on our roadmap.”

    Glad to see that remark because halfway through the article I was going to mention that it would be great to see same level of integration for Maven… Currently it’s a bit cumbersome and difficult (especially compared to NetBeans where you can easily open multiple maven projects and then simply rebuild when needed… and also cross-project navigation works much better there – Idea is lacking much in this aspect….)

  3. Alex Katlein says:

    October 14, 2016

    What’s up with those new icons? They don’t pop anymore which kind of makes them disappear.
    Also they are no longer bright and shiny, which makes it difficult to tell them apart.

    Did you let an intern design them?

    • Alex Katlein says:

      October 14, 2016

      Don’t want to bash the icons, they certainly look “cool”, it’s just that the UX suffers in my eyes!

    • Leo says:

      October 14, 2016

      Yup, loving the look of those, but I’m wondering if they really improve usability.
      I think most of them could use a bit brighter palette.
      On the positive side, there’s a better consistency about the overall look.

      • Konstantin Bulenkov says:

        October 14, 2016

        Alex, Leo, thank you for feedback.
        Leo, what color theme you use? Darcula or Default?

        • Leo says:

          October 18, 2016

          Hi Konstantin!

          I use Darcula. I would say that the one that changed the most is between the normal folder and code folder (the small dot). Before the difference was bigger.

          However the biggest “design” complaint I’ve got is still https://youtrack.jetbrains.com/issue/IDEA-149537. Black small icon is just a bad idea (even more now with the grey folders).

          But really, great job, Jetbrains makes the most visually appealing IDEs out there.

    • Louis Bergelson says:

      October 21, 2016

      I’m not a big fan of the new icons. They seem much more uniformly grey and low contrast. The bright yellow ignored folders are cheerful, but it’s calling attention to exactly the folders that I want to not pay attention to. The old subdued red in that case was more functional (especially since red has a stronger association with “stop, ignore, etc”).

      I really preferred the folder icons that had bright borders instead of the solid grey/green. Medium greys have very little contrast with the white background unless my monitor is turned way up. (and it’s hard to tell them from the green folders at a glance) I definitely think the older folder icons with the crisp outlines were more readable.

      I think some of the other icons were more readable in their older forms as well. The older library icon used to be much more understandable / more distinct for instance. The new library folder reads as a grey folder with 4 wobbly grey lines on it since at small sizes the grey/blue/green bars are indistinguishable from each other. The older version with the red book didn’t have that problem. The solid grey folder is just very hard to distinguish anything against.

      In general I think the new icons need more contrast and less grey. I’m running on a retina display, so maybe they look more distinct at lower resolutions.

  4. Pete says:

    October 14, 2016

    IntelliJ won’t start after the update, get an error stating it failed to invoke the main method

    • Pete says:

      October 14, 2016

      After uninstalling(not just a rollback) and reinstalling it is running fine

  5. Robin Sander says:

    October 14, 2016

    Is there some further documentation about the build delegation to Gradle besides IDEA-131627? Especially regarding the separation of such a build and a Gradle build started from the command line. Is separation of build outputs still supported? Does IntelliJ use its own Gradle daemon or is there some risk of locking?

    • Vladislav says:

      October 17, 2016

      Why do you want to separate gradle builds started by IDE?
      >>Is separation of build outputs still supported?
      No, it makes sense only when IDE uses internal compiler for the project build
      >>Does IntelliJ use its own Gradle daemon or is there some risk of locking?
      IntelliJ uses gradle toling api and does not manage Gradle daemons.
      There should not be risks of gradle daemon locking since gradle is able to start several daemons if one is busy.
      And it doesn’t matter who starts the daemon, command line task invocation or someone using toolning api call.

      • Robin Sander says:

        October 18, 2016

        Why do I want to separate gradle builds started by IDE?
        The answer is simple: because IntelliJ is unreliable when it comes to building artifacts.
        There are still some issues regarding the build of a WAR (simply search youtrack for ‘gradle war’) but even if not, one new issue or incompatibility with a new Gradle plugin or feature, issues with annotation processing, …, you name it, would be enough to break the whole build cycle.
        That’s why I’m using the command line for building (an inplace WAR) and deployment. In combination with remote debugging this works perfectly and was reliable across several major releases of IntelliJ and different deployment servers.
        Now while I’m curious to use the new build delegation feature I fear that, without separation of build output the two builds will interfere with each other or that a local build causes the IDE to slow down.

        • Vladislav says:

          October 18, 2016

          >>The answer is simple: because IntelliJ is unreliable when it comes to building artifacts.
          It seems you didn’t get the idea of build/run delegation feature.
          The actual work (e.g. war/ear assembling or sources compilation) will be done by gradle not by IntelliJ. IDE will delegate the job to gradle. So, you will get the same results as if you would use command line.
          Using the feature you can get the power of both worlds: e.g. create artifacts by gradle and use IDE integrations to deploy it into your JEE server.
          The workflow can be as following (assuming enabled feature):
          1. Import gradle web project
          2. Create Tomcat Run Configuration
          3. Choose war artifact you wish to deploy
          4. Start Tomcat Run(or Debug) Configuration
          That’s it.

          Btw, the feature is optional, so you can turn it on only if you wish.
          Just, try it and send us your feedback in youtrack, thanks.

  6. Konstantin says:

    October 14, 2016

    Be careful with this EAP! FindBugs-IDEA (https://plugins.jetbrains.com/plugin/3847?pr=idea) stops working with an exception “Access is allowed from event dispatch thread only.”

  7. Johan Nordberg says:

    October 14, 2016

    Looks very useful! Wish there was something similar for Resharper / Rider and NuGet packages.

  8. popalka says:

    October 14, 2016

    I tried Gradle composite builds in new EAP.
    It’s work on sample project, provided with gradle 3.1 distribution.
    But it doesn’t work on my big real-life project. IDEA use binary dependencies instead of module ones as it was before. I will try to investigate and create bug report.

    • popalka says:

      October 14, 2016

      I found the cause. In my case artifacts from lib uploaded to corporate maven repo with overwritten names.

  9. Serhii says:

    October 14, 2016

    Cool new icons ^__^

    • Konstantin Bulenkov says:

      October 14, 2016

      Thanks!

  10. Igor Kolomiets says:

    October 14, 2016

    “If you’re using Maven, don’t worry: adding a similar feature for Maven is on our roadmap.”

    Please, please, please and thank you!!!

  11. Alex Z says:

    October 14, 2016

    Flatten packages option is broken: https://youtrack.jetbrains.com/issue/IDEA-162635

  12. Adrian Perez says:

    October 17, 2016

    Yeah the new icons are hard to distinguish at all using Darcula theme. Hope they fix it or revert back to the old ones.

  13. Louis Bergelson says:

    October 21, 2016

    The new gradle composite feature seems excellent so far! Thank you so much for adding that! It is going to be a massive productivity boost for my team.

    It seems like it might be more discoverable if it was configured from the project structure page instead of a right click menu in the gradle configuration.

  14. Dominik says:

    October 27, 2016

    Maybe I am missing something, but does this “Composite Build” logic – either with Gradle directly or with IntelliJ 2016.3 – respect the versions of the dependencies which are set in the build.gradle files? I just tried it out and it _either_ takes the local project and includes that instead of the binary artifact _or_ it takes the artifact. It seems to ignore the version number when making that decision.

    Our usecase is to test our code with a released version (not in the project/workspace) once in a while, but changing the version of the dependency does – at least in IntellJ – not add the commons module as external dependency. Once a composite build, always a composite build seems to be the mantra.

  15. Henry says:

    November 22, 2016

    New icons are SO UGLY!!! They are NO LONGER BRIGHT!!! So hard to distinguish!!!! All other features are good, but why you change this???

  16. Andrew says:

    November 27, 2016

    I also find the new folder icons hard to see in Darcula. I need more contrast!!! It would be great if you could provide the option of using the old ones instead.

  17. Tamer says:

    December 2, 2016

    I’m keep having this error in gradle sync panel:

    Error:Cause: org.gradle.internal.component.external.model.DefaultModuleComponentSelector

    I checked all libraries version.. any Idea?

    • Vladislav says:

      December 6, 2016

      It looks like you use some gradle plugin in your project which is incompatible with the gradle version you use.

      • Tamer says:

        December 9, 2016

        How can I identify it? shouldn’t be the error message more clear?

  18. Jones says:

    December 14, 2016

    Is it already included in Android Studio, or is it in IntelliJ only?

    • Jones says:

      December 14, 2016

      More precisely, I’m interested in the Composite Build integration

    • Andrey Cheptsov says:

      December 15, 2016

      Android Studio 2.3 is based on 2016.2

  19. Jones says:

    December 15, 2016

    I am not completely clear about Android Studio: I have Android Studio 2.2.3, but I don’t see the “Composite Build Configuration” in the Gradle tool window.

    Is it already deployed in Android Studio? The title mentions both IntelliJ and Android Studio 2.2…

    Thanks! =)

  20. James justin says:

    May 29, 2017

    Nice icon but already included in Android studio

  21. Paul says:

    November 24, 2017

    I’ve sucjh error because I wrongly specified the compiled cloud version, so gradle was not able to boot it))

  22. James Nelson says:

    March 21, 2018

    Just want to toss this out there… We had previously setup our build to have a gradle.properties flag to turn on composite build when a given property is turned on. Worked great in previous versions of IJ, and we would have both IDE and command line using (or not using) composite builds correctly. Since this update, turning on both causes IntelliJ to use jars instead of project dependencies, and the only way to make it work is keep the property off in the file, and just pass a command line parameter when building on CLI.

    Is there any testing around cases where user has enabled composite build in their settings.gradle, and then turning it on in IDE as well? I spent over a week getting things just right, and then after users updated and everything broke, I looked pretty bad in the eyes of the CTO :'(

  23. aditya singh says:

    April 20, 2018

    Your blog is nice

  24. Praveen says:

    May 16, 2020

    Nice futures to use it in android studio. Thanks

Subscribe

Subscribe for updates