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

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!

This entry was posted in EAP Releases, New Features and tagged , , , , , . Bookmark the permalink.

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

  1. Xenophon says:

    New Icons? Cool! But what about retrograde users?

    • Konstantin Bulenkov says:

      Hello Xenophon.
      For retrograde users we have something like this But I wouldn’t call a person who uses IntelliJ IDEA EAP a retrograde user 😉

      • Mikhail Kholodkov says:

        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:

    ” 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:

    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:

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

    • Leo says:

      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:

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

        • Leo says:

          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 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:

      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:

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

  5. Robin Sander says:

    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:

      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:

        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:

          >>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:

    Be careful with this EAP! FindBugs-IDEA ( stops working with an exception “Access is allowed from event dispatch thread only.”

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

  8. popalka says:

    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.

  9. Serhii says:

    Cool new icons ^__^

  10. Igor Kolomiets says:

    “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. Adrian Perez says:

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

  12. Louis Bergelson says:

    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.

  13. Dominik says:

    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.

  14. Henry says:

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

  15. Andrew says:

    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.

  16. Tamer says:

    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?

  17. Jones says:

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

  18. Jones says:

    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! =)

  19. James justin says:

    Nice icon but already included in Android studio

  20. Paul says:

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

  21. James Nelson says:

    Just want to toss this out there… We had previously setup our build to have a 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 :'(

  22. aditya singh says:

    Your blog is nice

Leave a Reply

Your email address will not be published. Required fields are marked *