JetBrains IntelliJ IDEA Blog

16 Responses to “Gradle Support”

1. Felipe Cypriano Says:
   August 21st, 2009 at 2:38 pm

   Very nice!

2. Dierk König Says:
   August 21st, 2009 at 3:46 pm

   So cool to see gradle support in Maia!
   Keep it up!

3. Erik Says:
   August 21st, 2009 at 4:09 pm

   Please, consider taking a look at Schmant as well. I just know that the IntelliJ developers will like it much much better than Ant, Maven and Gradle. Would be great to have IntelliJ support for Schmant.

4. Anatol Says:
   August 22nd, 2009 at 1:37 am

   I think it is a step in the right direction. Java community needs good/extensible build tool. Unfortunately neither Maven nor Ant are good. So Gradle plugin could make it popular for developers who uses IDEA.

   The only concern is a speed. The build tool (as any other tool) should be fast. I dont think that a tool written in Groovy could be fast. Well, “HelloWorld” example could take a second, but what about project with 100K java files & 2K build targets. Would Gradle manage it effectively?

5. Wpfeiffe Says:
   August 24th, 2009 at 7:17 am

   To Anatol:

   Although Groovy doesn’t quite have the speed of java, it is getting better. However, my guess is that the Groovy script portion of Gradle is merely the glue and represents a small fraction of the running code. Overwhelming portion build time is likely spent in calling javac, jar, dependancy checking, and underlying code which is (I think) written in java.

6. Hans Dockter Says:
   August 25th, 2009 at 8:40 am

   This is excellent news. A big thank you to IntelliJ.

   Regarding the performance questions. You might subdivide the performance of a build tool into three categories:
   1.) Startup time
   2.) runtime performance of the build tool
   3.) smartness of the build tool.

   1.) We have a little higher startup time due to the fact that we use a Groovy DSL. We have some optimizations in the pipeline, but Gradle will always takes a bit longer to startup than let’s say Ant. For even a simple build this doesn’t matter much. The only area were I really perceive this as slow is when I execute for example ‘gradle -t’ to get a list of all available tasks. We always have the option in the future to ship a Gradle console (or UI) were we would preconfigure the JVM.

   2.) The Gradle core is written in Java. So there is no conceptual reasons why Gradle should be slow. And in reality this is also not the case. We are also continuously optimzing our runtime performance.

   3.) I think this is the most important aspect for build execution. What about multi-threaded test execution (a Gradle 0.8 feature)? What about smart task with MD5 checking and history awareness to decide whether they should do something or not? What about a state of the art incremental compile feature (future Gradle)? There are many ways to make in particular enterprise builds much faster and yet reliable. This is one of the focus for Gradle 0.8.

   –
   Hans Dockter
   Gradle Project Manager
   http://www.gradle.org

7. Brendon Says:
   August 25th, 2009 at 10:50 am

   Am I correct in assuming that I could create a Groovy facet, and use Gradle to build a pure Java project?

8. Steve Appling Says:
   August 26th, 2009 at 11:55 am

   I’m very happy that IDEA will include Gradle support, but find it odd that it is done through the Groovy facet. Why should I have to have a Groovy facet if I’m not using Groovy in my project. Gradle is just a build tool and does not imply any use of Groovy in your project. Wouldn’t you find it odd to require a Groovy facet to be able to use Ant? Won’t this cause problems if I am using Groovy, but need a different version of groovy than the one used in Gradle?

   It seems like a Gradle installation should be independently selectable in a Gradle plugin like an Ant one is.

9. Hans Dockter Says:
   August 26th, 2009 at 2:03 pm

   Yes. That would work without a problem.

10. Peter Gromov Says:
    August 27th, 2009 at 5:48 am

    Steve,

    Actually you don’t need a Groovy facet, it just provides a user-friendly interface to add Gradle to classpath. Actually it’s the Gradle library in classpath which enables Gradle support, and it’s necessary. So there’s currently no way of having different Groovy and Gradle versions in one module. Maybe there will be one in future.

    Do you have any suggestions on how to make the Gradle configuration more intuitive, natural and Groovy-independent?

11. Peter Niederwieser Says:
    August 29th, 2009 at 3:56 pm

    Great to see some Gradle support in Maia! Now I’m waiting for the killer feature - the ability to import a Gradle project into IDEA…

12. Steve Appling Says:
    September 2nd, 2009 at 2:41 pm

    I would think it would be more natural to just define the location of the gradle install in a plugin - just like you specify an ANT install. This is a project level setting (not per module) and seems like it should be a property of the plugin. It seems very strange to be required to put my build tool in the classpath for my product. I don’t want the gradle classes accessible at runtime by my project’s code. Wouldn’t you find it odd to require ant.jar to be added to a module’s classpath to get ant support? Why is Gradle handled differently?

13. Peter Gromov Says:
    September 2nd, 2009 at 3:06 pm

    Steve,

    Yes, you’re completely right. I doubt a bit whether it should be per-project or per-application setting, but I’m going to start with per-project and see what happens. The work is in progress and may be finished before the next EAP.

14. Roger Studner Says:
    November 12th, 2009 at 8:48 pm

    Well, the make key, to me, for all of this.. is that Intellij will be able to auto-configure the “lib” dependencies of a project via a gradle build script.

    m2eclipse, and the ivyde plugins for eclipse… always were so painful about this part.. which in the end turned the IDE into a “text editor” and all build work had to be done outside the IDE, with jars being manaually copied around.

    blech!

15. Peter Gromov Says:
    November 13th, 2009 at 7:19 am

    Roger,

    No, we’re not running Gradle scripts to extract dependencies. Sounds like a nice feature or idea for a separate plugin.

16. Roger Studner Says:
    February 14th, 2010 at 11:46 pm

    All sorts of ways this isn’t right now.

    a) there isn’t a groovy facet.. it is Add Framework Support.

    b) Gradle 0.8/lib bundles groovy 1.6.4.. what if you are already using groovy 1.7

    Just not sure if this is a “feature” in any way anymore