Gradle - A new Build System

Discussions

News: Gradle - A new Build System

  1. Gradle - A new Build System (48 messages)

    We would like to introduce you to Gradle, a new build system that uses Groovy for its build scripts. http://www.gradle.org Gradle provides:
    • A very flexible general purpose build tool like Ant.
    • Switchable, build-by-convention frameworks a la Maven (for Java and Groovy projects). But we never lock you in!
    • Powerful support for multi-project builds.
    • Powerful dependency management (based on Apache Ivy).
    • Full support for your existing Maven or Ivy repository infrastructure.
    • Support for transitive dependency management without the need for remote repositories and pom.xml or ivy.xml files.
    • Ant tasks as first class citizens.
    • A wrapper to run Gradle builds on machines where Gradle is not installed (e.g. continuous integration server)
    • Groovy build scripts.
    Our 50+ pages user's guide contains tutorials, a detailed overview and in-depth coverage. The Gradle project itself is highly automated by its Gradle build. As documented, it runs happily on Teamcity and Bamboo (where Gradle is not pre-installed). -- Hans Dockter Gradle Project lead http://www.gradle.org

    Threaded Messages (48)

  2. Gant...[ Go to top ]

    Does Gradle has the same purpose as Gant?
  3. Re: Gant...[ Go to top ]

    Does Gradle has the same purpose as Gant?
    The founder of Gant, Russel Winder, has described Gant with the words:
    Gant is just trying to be a way of scripting Ant tasks to use Ant but without any XML.
    Gradle offers this as well, but just as one of many other features. The fact that Gradle computes the complete dependency graph before anything is executed offers many possibilities Ant, Maven or Gant can't offer. Another things is, that in Gradle the declared targets (Gradle call's them differently) are objects with a rich API. You can manipulate them at any point in your build script, which means also from any project of a multi-project build. We think Gradle has the best multi-project support out there. Gradle scales from very simple projects to complex enterprise environments. The way you use Gradle for writing your build is very natural for a software developer. You do it via calling rich API's. This feels not just natural, it is also very powerful.
  4. Great another one[ Go to top ]

    Yet another tool that does something other tools do very well already.
  5. Re: Great another one[ Go to top ]

    I would have not started to develop another tool if this were the case. Or is there a tool I don't know of yet?
  6. Re: Great another one[ Go to top ]

    What I am missing in the discussion is a comparison with maven 2. Maven 2 also is a nice concept that supports transitive dependencies. It has a few flaws, like: 1. dependencies are only defined for artifacts like jars but not for other things such as plugins. For instance, if I am using hibernate then I would also like to be able to declare (once) a set of dependencies for test tools and perhaps some plugin configuration. Currently, this can only be done by pom inheritance, but that is limited because multiple inheritance is not supported. 2. duplication in multiproject builds. It requires me to specify versions for dependencies that are part of the same build. Other, issues are that refactoring support in IDEs is still a bit behind. For instance, 'refactor artifact' (renaming a dependency's groupId and/or artifactId and/or version). Apart from this, I think the maven concept is great. When I see the examples of Gradle, I am still left with one main question: What problem does it solve? In my view, the difference between ant and maven is that in maven one is allowed to script when needed and in ant one must script. With gradle, it appears that it is mandatory to script again. Because of the declarative nature of maven, IDE plugins that translate back and forth betweeen IDE projects and maven POMs is possible. How can something like that be realised with gradle? Cheers Erik
  7. Re: Great another one[ Go to top ]

    What I am missing in the discussion is a comparison with maven 2. Maven 2 also is a nice concept that supports transitive dependencies. It has a few flaws, like:
    1. dependencies are only defined for artifacts like jars
    but not for other things such as plugins. For instance,
    if I am using hibernate then I would also like to be
    able to declare (once) a set of dependencies for
    test tools and perhaps some plugin configuration.
    Currently, this can only be done by pom inheritance, but
    that is limited because multiple inheritance is not
    supported.
    This is possible with Gradle. For your Maven2 comparison check list: Better handling of dependencies.
    2. duplication in multiproject builds. It requires me to
    specify versions for dependencies that are part of the
    same build.
    Gradle has a very flexible and powerful support for configuring multi-project builds. It is way beyond to what you can do with Maven (see user's guide chapter 13). In Gradle you don't specify common behavior of subprojects via inheritance (one severe limitation of Maven is single inheritance). In Gradle the parent project is a container and you can iterate over its children to inject configuration. subprojects { dependencies { compile "javax.servlet:servlet-api:2.5" } type = 'war' } Under the hood we iterate over the subprojects and apply this configuration to them. You can do the same for a subset of subprojects based on a filter.
    Other, issues are that refactoring support in IDEs is still a bit behind. For instance, 'refactor artifact' (renaming a dependency's groupId and/or artifactId and/or version).

    Apart from this, I think the maven concept is great.
    Maven deserves a lot of credit for introducing the idea of build-by-convention. Maven did this long before the convention-over-configuration approach became popular due to Rails. Yet I think the implementation of Maven2 is seriously flawed in many ways. Gradle does support build-by-convention. It uses the same conventions for project layout as introduced by Maven2.
    When I see the examples of Gradle, I am still left with one main question: What problem does it solve?
    Two problems you have mentioned yourself above ;) I try to answer this question from a more fundamental perspective. We think build-by-convention is a great concept for a build system. But it must be accompanied by the freedom and power to solve the unique problems of a particular build. Otherwise build-by-convention becomes a prison. We think this is biggest flaw of Maven2 and we think Gradle does much better here.
    In my view, the difference between ant and maven is that in maven one is allowed to script when needed and in ant one must script. With gradle, it appears that it is mandatory to script again. Because of the declarative nature of maven, IDE plugins that translate back and forth betweeen IDE projects and maven POMs is possible. How can something like that be realised with gradle?

    Cheers
    Erik
    As said above, Gradle supports build-by-convention. So if you have a simple java project your Gradle script looks like this: usePlugin('java') group = 'com.brakkee' version = '1.0' You execute 'gradle libs' and the jar is generated. Gradle is declarative, but you use a powerful language for declaring your build. Therefore it is perfectly possible to extract the IDE configuration files out of a Gradle build. This is not implemented yet but is on the top of our list. Eventually we will put 'Gradle compared to X' documents on our webpage. Right now I really recommend to read our user's guide. It will answer your questions in-depth by presenting the features of Gradle.
  8. Re: Great another one[ Go to top ]

    in maven one is allowed to script when needed
    In script based solutions you could do the same using inheritance.
    the declarative nature of maven
    Script based build systems can be declarative as well, and IDE integration is possible as well. The problems I have with Maven 2 are: Debuggability: It's hard (impossible?) to debug a build. Maven projects magically work, or they don't. Tests are run as a different process: If I kill the build sometimes a test process doesn't stop. And how do I create a thread dump in Windows if a test hangs? XML: Easy to make a typo. No autocomplete in my IDE. I don't blame the IDEs however - it is probably very hard to support Maven in an IDE. Builds are really slow. It's always downloading a lot of stuff I didn't know is required. Hard to extend. For example, I need to switch the source code to the correct JDK before the build. I would probably have to write a 'plugin'. I don't know how to do that and I don't want to know. It scares me ;-) It's probably easier to write my own build system than doing that.
  9. Thank goodness![ Go to top ]

    I loved Maven for its use of convention and dependency injection, but.. XML is still XML, and a pain when you want to do something not declarative. Dynamic languages are perfect for this sort of thing, and being able to use a single language to describe things both declaratively and procedurally makes life so much easier. Maybe enough projects like this will eventually convince people that logic should not be defined with markup.
  10. Re: Thank goodness![ Go to top ]

    I loved Maven for its use of convention and dependency injection, but.. XML is still XML, and a pain when you want to do something not declarative.
    That is when you write a plugin for Maven, even using one of the scripting languages. Generally, scripting, (if used without care) can break lots of things. For example, reusable build process or project auditability. You can't easily visualize what is going on in the build script and dynamic languages only make it harder.
  11. Re: Thank goodness![ Go to top ]

    That is when you write a plugin for Maven, even using one of the scripting languages.
    Of course a build script should not contain complex build logic. Gradle offers a couple of ways to organize your build logic. If the logic is very simple, you just put it in the target (Ant terminology). If it is slightly more complex and used by multiple targets you can extract into a method. If it is more complex you want to refactor it into classes. For complex scenarios, a build script should rather act like a controller in a web application. Just coordinating things and delegating to a domain model. It all depends on your problem space. Simple things should be simple to solve without unnecessary indirections. Complex things should be properly organized. If you want to use classes with Gradle to organize parts of the build logic you simply drop them in a certain folder. They get automatically compiled (and tested if you supply tests) as part of the build and you can access them in your build script. And there is another huge difference between using classes (aka domain model) from Gradle compared to using plugins from Maven. Maven offers only an anemic interaction with a plugin. You have to call it via XML, have a limited set of types you can pass to it and can't use return values. Why on earth shouldn't I use my classes liked I'm used to when developing in Java. With a rich type system, with loops, with the possibility to use return values and with writing one line instead of twenty.
    Generally, scripting, (if used without care) can break lots of things.
    I think build masters don't need a product that tries to save them for themselves. They need a sharp tool. Any tool used without care can break a lot of things. The question is, whether a build system allows you to be productive, scales with the project complexity (up and down) and is capable, if used properly, to yield a maintainable build. Is this the case for Maven2?
    For example, reusable build process or project auditability. You can't easily visualize what is going on in the build script and dynamic languages only make it harder.
    Have you really had a look at Gradle? Or is this rather a pavlov-reaction after you read the word Groovy ;) Gradle creates a nice directed acyclic graph of all its tasks (aka targets) before it executes anything. Right now you can print this information only to the console, in the future it would be nice to offer a real graph. Is Maven better than this? Maven is the only major build tool which does not use dependency graphs. I'm not sure if this was a good design decision. It would be nice if you could explain what you mean with reusable build process and project auditability. If the first means build-by-convention, well, Gradle supports this and uses in fact the same project layout as Maven2.
  12. Why not Java?[ Go to top ]

    Groovy is a 6 MB download and a new language and is not integrated in my IDE (no autocomplete, debug,...). Java is much easier. I don't buy the argument that it is 'harder' to write build script in Java. I started to write my own Ant replacement 'JAnt'. The build tool is 16 KB (one Java class, 11 lines shell script, 6 lines batch file). It can download dependencies, invoke javac, javadoc, copy, filter and delete filter files, and create zip and jar files. I don't need much else, and if I need I can download it. The build script itself is a simple Java class: http://code.google.com/p/h2database/source/browse/trunk/h2/src/tools/org/h2/build/Build.java I use this now for my project H2 at http://www.h2database.com
  13. Re: Why not Java?[ Go to top ]

    Hi Thomas,
    Groovy is a 6 MB download and a new language and is not integrated in my IDE (no autocomplete, debug,...).

    Java is much easier. I don't buy the argument that it is 'harder' to write build script in Java.
    this is a valid question. In fact we have asked and answered the same question in Gradle's users' guide, section 5.2. First of all, the IntelliJ IDE offers fantastic support for Groovy and thus for Gradle. I don't know about the state of the Groovy Eclipse plugin (See Appendix B of the users' guide) Gradle is not _first_ of all Groovy. It is a build system which adds new concepts to the build system space. Those concepts just require a language for its build scripts, which is capable of interacting with an (Java) API. So no XML. This language could be Java, Groovy, Jython, Javascript or JRuby. In fact we plan to support other build script languages than Groovy in the future. Yet we think Groovy is a perfect match as a build script language for Java projects. Compared to Java it makes a significant difference regarding productivity and maintainability of the build scripts. For two reasons: One is of fundamental nature. It is discussed in an article about Lisp, Ant and XML. Java does not allow you to introduce new language elements. Therefore you have to write:
    CopyTask copy = new CopyTask(); Fileset fileset = new Fileset(); fileset.setDir("src_dir"); copy.setToDir("../new/dir"); copy.setFileset(fileset); copy.execute();
    With XML and Groovy you can introduce such elements. In Groovy you can write:
    copy(dir: "../new/dir") { fileset("src_dir"); }
    The author of the article above argues that this is a major reason why Ant has become so successful. There is important reason, why we think Groovy is such a good match and these are its power features. Specially for project automation there are so many tasks which are so much easier to implement with Groovy than with Java. Handling of files, text templates, working with Streams. Believe it or not, there are many tasks which is just do with Groovy. It's fun at I am very productive. With Java I would think, let's look for a library or I might think, lets' do it later. This is at least my subjective experience. This is no boring Java bashing. Groovy is simply 10 years younger and could pick up many, many good things. Having said this, we love to offer choice to our users. A Java implementation of the Gradle's build script engine (this is a tiny part of Gradle) would be very cool.
    I started to write my own Ant replacement 'JAnt'. The build tool is 16 KB (one Java class, 11 lines shell script, 6 lines batch file). It can download dependencies, invoke javac, javadoc, copy, filter and delete filter files, and create zip and jar files. I don't need much else, and if I need I can download it. The build script itself is a simple Java class:
    http://code.google.com/p/h2database/source/browse/trunk/h2/src/tools/org/h2/build/Build.java

    I use this now for my project H2 at http://www.h2database.com
    What for example about transitive dependency management and multi-project build support? The focus of Gradle is not just building, it is about project automation. For example Gradle is being build by Gradle. The actual Java/Groovy stuff (compiling, testing, producing the jar) is a tiny part of the build and is provided out of the box by Gradle. The interesting things are for example: Automatic Release Management: We just execute gradle release: Our build knows the version of the last release. Then it checks the svn path of the working copy. If we are in a release branch and there has been a release before, the build does a revision release (including tagging). If we are in trunk it does a major/minor release, creates the branch and tags the release. Userguide: The userguide is generated. Most of the examples in the userguide are also integration tests. Our build executes these integration tests, and if they pass, the output and the sources of the tests are included in the userguide. Upload: We have the task uploadDists. Gradle allows a build to check the execution graph and do further configuration before anything is executed. If the 'release' is in the graph, we upload the distributions to the release destination. If the 'release' task is not in the graph, the version number gets an additional snapshot id and is uploaded to the snapshot repository. I could list more things we do for Gradle's project automation. And after all Gradle is a rather simple project from a build perspective. You need a good build system for this kind of project automation and you want to have one tool for simple and very complex projects which scales according to the needs. P.S. H2 is my favorite embedded database. It has solved all the pain points I had with either Hsql or Derby.
  14. Re: Why not Java?[ Go to top ]

    I didn't want to say that Gradle is 'bad' (how could I, I didn't even test it). From what you describe it certainly has a lot of features and I am not a Java fanatic (I like to learn Scala when I have time). But for very simple projects it is (in my view) better to have a very lightweight build tool. What about a multi-level build tool? The initial shell script / batch file compiles the level-1 build definition and the level-1 build tool (if required) and runs it. For simple projects (like my project H2), nothing else is required. For more complex projects, the level-1 build downloads the level-2 build tools, compiles the level-2 build and runs it. The level-1 could be written in Java, while level-2 could be another language. CopyTask copy = new CopyTask(); Fileset fileset = new Fileset(); fileset.setDir("src_dir"); copy.setToDir("../new/dir"); copy.setFileset(fileset); copy.execute();
  15. Re: Why not Java?[ Go to top ]

    I am sorry, incomplete post... CopyTask copy = new CopyTask(); Fileset fileset = new Fileset(); fileset.setDir("src_dir"); copy.setToDir("../new/dir"); copy.setFileset(fileset); copy.execute(); Could be written as: copy("../new/dir", getFiles("src_dir"));
  16. Re: Why not Java?[ Go to top ]

    copy(dir: "../new/dir") { fileset("src_dir"); }The author of the article above argues that this is a major reason why Ant has become so successful.
    For me this is one of the major weaknesses of Ant. I always have to look up the syntax, and more complex cases are basically trial and error. You can not even debug it. You can easily debug code like:FileList files = getFiles("temp"). exclude("temp/org/h2/dev/*"). exclude("*.bat"); jar("bin/h2.jar", files, "temp");
    Why don't you publish it as a separate "project" so that others can use it too :) ?
    'My' tool is already open source, feel free to use it or create a project :-)
  17. Re: Why not Java?[ Go to top ]

    copy(dir: "../new/dir") {
    fileset("src_dir");
    }The author of the article above argues that this is a major reason why Ant has become so successful.
    For me this is one of the major weaknesses of Ant. I always have to look up the syntax, and more complex cases are basically trial and error. You can not even debug it. You can easily debug code like:FileList files = getFiles("temp").
    exclude("temp/org/h2/dev/*").
    exclude("*.bat");
    jar("bin/h2.jar", files, "temp");

    If you look at Gradle's user's guide (7.1 Configuring Tasks), you will find that most of Gradle's tasks support your favorite a notation (similar to for example Hibernate Criterias). It gives you IDE support and you have to define the context only once. But I don't think it is as readable, in particular if it get's long and nested. You always have to deal with the dot operator. And creating new Entities is not as nice as it is with the other notation:
    List cats = sess.createCriteria(Cat.class) .add( Restrictions.in( "name", new String[] { "Fritz", "Izi", "Pk" } ) ) .add( Restrictions.disjunction() .add( Restrictions.isNull("age") ) .add( Restrictions.eq("age", new Integer(0) ) ) .add( Restrictions.eq("age", new Integer(1) ) ) .add( Restrictions.eq("age", new Integer(2) ) ) ) )
    You could avoid the use of the repetitive use of Restrictions with static imports. But they pollute the whole namespace of the class. And with Groovys builder notation you can do smart stuff in between. The structure does not have to be a 1:1 mapping to the underlying domain model. also Groovies named parameters are nicer than having to implement them the way above (e.g. "age: new Integer(2)). And it is provided by Groovy you don't have to implement it yourself like the Criteria API has to. Therefore Gradle favors the alternative, Ant-style notation, which is more expressive I think. The good news is, that IDE support for this pattern is possible and basically already implemented by IntelliJ. And as I understand you, missing context assistant is your major objection against this notation. Of course you can debug your Gradle build file. By the way, IntelliJ also provides very nice content assistance for the Ant tasks in a build.xml.
  18. Re: Why not Java?[ Go to top ]

    I didn't want to say that Gradle is 'bad' (how could I, I didn't even test it). From what you describe it certainly has a lot of features and I am not a Java fanatic (I like to learn Scala when I have time). But for very simple projects it is (in my view) better to have a very lightweight build tool.

    What about a multi-level build tool? The initial shell script / batch file compiles the level-1 build definition and the level-1 build tool (if required) and runs it. For simple projects (like my project H2), nothing else is required. For more complex projects, the level-1 build downloads the level-2 build tools, compiles the level-2 build and runs it.
    Gradle could support Java build scripts. On the other hand Groovy shares so much with Java. You usually can paste your Java code into Groovy and it works. The learning curve is low for Java developers. Besides this, I think even simple builds benefit from a directed acyclic graph to organize the tasks. Gradle offers you to build up such a graph, on the other hand you can easily define your normal methods or refactor your build logic to a domain model if required. I think such a level-1 - level2 cascade would make things more complicated.
  19. Re: Why not Java?[ Go to top ]

    I think even simple builds benefit from a directed acyclic graph to organize the tasks.
    The build for really simple projects could be defined by the directory structure (as in Maven). Then you don't need to define anything, or organize the tasks.
    A level-1 - level-2 cascade would make things more complicated.
    If I create a small project, I don't want that people need to download 10 MB for the build tool. And if your build tool depends on Groovy you need to download Groovy. This 'large build tool for small project' is not only a problem for Grails, the same applies to Maven and (less so) to Ant. I think that many simple projects would benefit from a small and simple build tool. If it's only 20 KB, it can be embedded in the application itself. That would be level-1. I have the impression that you try to solve the problem of large projects. In my view you should also think about small projects.
  20. Re: Why not Java?[ Go to top ]

    I think even simple builds benefit from a directed acyclic graph to organize the tasks.

    The build for really simple projects could be defined by the directory structure (as in Maven). Then you don't need to define anything, or organize the tasks.
    Build-by-convention is offered by Gradle!
    A level-1 - level-2 cascade would make things more complicated.

    If I create a small project, I don't want that people need to download 10 MB for the build tool. And if your build tool depends on Groovy you need to download Groovy. This 'large build tool for small project' is not only a problem for Grails, the same applies to Maven and (less so) to Ant.

    I think that many simple projects would benefit from a small and simple build tool. If it's only 20 KB, it can be embedded in the application itself. That would be level-1.

    I have the impression that you try to solve the problem of large projects. In my view you should also think about small projects.
    I hope this impression is wrong ;) What we try to provide is a build tool that scales up and down. I'm curios. What makes you think that we try to solve the problems of large projects only? Just the download size? We are very happy that we can solve many problems of large projects. But we are as happy that we keep simple things simple. Gradle is a build tool for simple and complex projects. Gradle is completely self contained. You only need an installed JDK. Gradle is bundled with Ant, Ivy and Groovy. The distribution-zip has an overall size of 6.5 MB.
  21. Re: Why not Java?[ Go to top ]

    I think that many simple projects would benefit from a small and simple build tool. If it's only 20 KB, it can be embedded in the application itself. That would be level-1.
    H2 or Gradle are rather simple from a build perspective. But any relevant project needs to share its libraries or distributions, needs release management and other things. You can do this manually. I don't think this is a good idea. There are many things beyond the compile cycle which can be automated. The compile - test - jar bit of the Gradle build of Gradle is tiny and comes out of the box. But the other aspects of project automation are challenging to solve. - Automatic Release Management - Integration Testing - Most of the example scripts of the user's guide are actual integration test which we include dynamically into the user's guide as part of the build (including there output). - Website Generation Having all this automated, makes releasing very reliable, cheap and takes the stress from this important step. Another example. A user had a problem with Gradle's windows script. I did a fix and just typed 'gradle uploadDists'. The build reckognizes that this is not a release, builds the dists with a snapshot number and uploads it to the snapshot repository. The user could try it out and I got FEEDBACK. This is another aspect of project automation. You are more agile and it is much easier to get feedback on your work. As soon as you have to do it manually you do it less frequent. When you take project automation into account, the idea of simple builds is a different one.
  22. Re: Why not Java?[ Go to top ]

    Groovy is a 6 MB download and a new language and is not integrated in my IDE (no autocomplete, debug,...).
    Well, if you use IntelliJ IDEA then Groovy (via JetGroovy plugin (free)) is in fact very well integrated (so is Grails).
  23. Re: Why not Java?[ Go to top ]

    Java is much easier. I don't buy the argument that it is 'harder' to write build script in Java.

    I started to write my own Ant replacement 'JAnt'. The build tool is 16 KB (one Java class, 11 lines shell script, 6 lines batch file). It can download dependencies, invoke javac, javadoc, copy, filter and delete filter files, and create zip and jar files. I don't need much else, and if I need I can download it. The build script itself is a simple Java class:
    http://code.google.com/p/h2database/source/browse/trunk/h2/src/tools/org/h2/build/Build.java

    I use this now for my project H2 at http://www.h2database.com
    Why don't you publish it as a separate "project" so that others can use it too :) ?
    From the example you mention it looks very nice and way much more simple than any other build system :).
  24. Do you support StarTeam? Thanks, Alex
  25. Do you support StarTeam?

    Thanks,
    Alex
    Gradle has no out-of-the-box behavior for version control systems. We plan a release management solution and other VCS functionality. We don't know yet which VCS systems we are going to support. Right now the Gradle build of the Gradle project has custom logic for doing the release management. Gradle lives on SVN and we use the svnkit library in our build code to handle this.
  26. Currently, there is no tool I am aware of that properly determines the dependencies between java class files and conditionally builds only (and all of!) what's needed. Neither ANT nor javac does this, and ANT's task routinely is unable to. The analog from the C world is the gcc -M option that will analyze the sources and create a dependency graph, so that if one .h file changes, it knows which .h and .c files need to be marked as out-of-date. This is ANT's biggest flaw. I can deal with it's horrible XML formatting and counter-intuitive tasks, but it is difficult to use as a day-to-day build tool. I must frequently recompile everything to make sure my changes are good. If your answer involves "Apache IVY", you are not understanding the question (or I am not understanding IVY; it seems to deal with jar/lib dependencies). Situation: I've got a 10,000 class java project. I change one file. javac and ant both recompile that file only. This (can) cause(s) runtime breakage. The ant depend task is somewhat better, but not sufficient (I'm not sure how it works, but some sort of static analysis is required, and it doesn't seem to do that). I need it to determine, based on the file I changed, what other files must now be recompiled (i.e. subclasses, users of the given class, etc.). We had this for C/C++, and it has been lost in Java.
  27. Currently, there is no tool I am aware of that properly determines the dependencies between java class files and conditionally builds only (and all of!) what's needed. Neither ANT nor javac does this, and ANT's task routinely is unable to.

    The analog from the C world is the gcc -M option that will analyze the sources and create a dependency graph, so that if one .h file changes, it knows which .h and .c files need to be marked as out-of-date.
    I know that Ant's javac is not doing a good here. Gradle is not doing a better job, as its right now delegates to Ant's javac. I haven't used Ant depend, but I'm going to have a look at it. For my projects this never had a high priority. The compile time has been always insignificant compared to the time for unit and integration testing. Therefore a clean did never really hurt. Its very good to learn that this is a real pain point for other people. I'm sure Gradle can improve here. Would you mind filing a Jira issue at http://jira.codehaus.org/browse/GRADLE ? There is a tool which does a better job here: It is Phytons Scons: http://www.scons.org/doc/0.98.2/HTML/scons-user/x3256.html


    This is ANT's biggest flaw. I can deal with it's horrible XML formatting and counter-intuitive tasks, but it is difficult to use as a day-to-day build tool. I must frequently recompile everything to make sure my changes are good.

    If your answer involves "Apache IVY", you are not understanding the question (or I am not understanding IVY; it seems to deal with jar/lib dependencies).
    It is funny that for some reason you expect such a bizarre answer. Obviously Ivy has nothing to do with your problem. ;)
  28. "I need it to determine, based on the file I changed, what other files must now be recompiled (i.e. subclasses, users of the given class, etc.). We had this for C/C++, and it has been lost in Java." Actually that is very true. Our typical build time could probably go down from 3-4 minutes to a few seconds. I'm not soure about other companies, but at my place a stable incremental compilation process would make us do the migration from ant to gradle (or any other build system). I don't like XML configuration, but our ant scripts are now very stable in production, so we're not really inclined to migrate unless there's a real killer feature. Maybe a lot of other companies think the same !?
  29. oh I'm not sour about other companies; I meant "not sure about other companies". nice typo though.
  30. "I need it to determine, based on the file I changed, what other files must now be recompiled (i.e. subclasses, users of the given class, etc.). We had this for C/C++, and it has been lost in Java."

    Actually that is very true. Our typical build time could probably go down from 3-4 minutes to a few seconds. I'm not soure about other companies, but at my place a stable incremental compilation process would make us do the migration from ant to gradle (or any other build system).
    That is interesting to hear. You are the second one requesting this. This feature is definitely going up in the priority. Would you serve as a guinea pig for this?
    I don't like XML configuration, but our ant scripts are now very stable in production, so we're not really inclined to migrate unless there's a real killer feature. Maybe a lot of other companies think the same !?
    It always depends where your pain points are. I think for many builds Gradle would be a quantum leap in terms of productivity and maintainability. On the other hand, you don't throw away easily an existing builds. Therefore we don't expect that anyone who has a stable build and is more or less happy with it is going to throw this away for Gradle. We would not even recommend this. But I know that there are many people who are extremely unsatisfied with there build and build system. They really suffer. And I mean complex enterprise builds. The whole project suffers because the build is not delivering what it could deliver, although many resources are poured into it. They build masters would be more than happy to switch the build system if there is a good alternative. We propose Gradle as this good alternative :) For our next release we plan to ease migration. We want to provide a tool which maps the dependency section of Maven pom files into a gradlefile. We also want to offer something, that maps the declaration of an Ant task to an Groovy expression. Gradle has also plans to cooperate with existing Ant or Maven builds. We want to enable an evolutionary, smooth way for Gradle to enter existing build landscapes.
  31. "I need it to determine, based on the file I changed, what other files must now be recompiled (i.e. subclasses, users of the given class, etc.). We had this for C/C++, and it has been lost in Java."

    Actually that is very true. Our typical build time could probably go down from 3-4 minutes to a few seconds. I'm not soure about other companies, but at my place a stable incremental compilation process would make us do the migration from ant to gradle (or any other build system).

    That is interesting to hear. You are the second one requesting this. This feature is definitely going up in the priority. Would you serve as a guinea pig for this?
    yes, if you need testers/evaluators, I can help you; but it will take at least until mid june since we're a small team and the holiday season begins. I'll contact you on the mailing list.
  32. Currently, there is no tool I am aware of that properly determines the dependencies between java class files and conditionally builds only (and all of!) what's needed.
    Unfortunately, there is no such tool and in fact there never can be such a tool. Java involves a technology called "Reflection" that is used to determine dependencies at runtime. If you can not know a dependency at compile time, how can you possible satisfy at at compilation? Guessing and Hints are unstable and bound to failure all the same!
  33. Unfortunately, there is no such tool and in fact there never can be such a tool. Java involves a technology called "Reflection" that is used to determine dependencies at runtime.

    If you can not know a dependency at compile time, how can you possible satisfy at at compilation? Guessing and Hints are unstable and bound to failure all the same!
    I'm well aware of reflection, but it is not so ubiquitous in all java programs that the entire notion of static dependency analysis should be abandoned! That's just lazy thinking. A huge percentage of dependencies could be determined by static analysis. Basically, every compile error found by recompiling the entire source tree should be detectable without having to do so.
  34. I'm well aware of reflection, but it is not so ubiquitous in all java programs that the entire notion of static dependency analysis should be abandoned! That's just lazy thinking.
    No, it's realistic thinking, to abandon static analysis during compile time. The problem is that reflection may not be ubiquitous but that you cannot *know* what you need to compile. Of course you might want to analyse, if any of your uses reflection like features, than you would need to analyse if any library you pass data into uses refection and so on. Or consider a method with signature "doSomething(Object)" that only uses the toString() method of Object. Depending on how you instantiate the instances (abstract factory, di) dependency analysis is screwed....
  35. javac, anyone?[ Go to top ]

    Or consider a method with signature "doSomething(Object)" that only uses the toString() method of Object.
    If your class has such a method, your class then depends on... Object and String. Look how hard that was! :p In addition, javac will compute compilation dependencies within a source tree, and will only recompile only files that have updated. Of course you can't compute every dependency for a project. Things like Factories and reflection are designed to loosen the coupling between dependencies so that replacements can be dropped in. But, that's not a Java specific problem.
  36. I'm well aware of reflection, but it is not so ubiquitous in all java programs that the entire notion of static dependency analysis should be abandoned! That's just lazy thinking.


    No, it's realistic thinking, to abandon static analysis during compile time. The problem is that reflection may not be ubiquitous but that you cannot *know* what you need to compile.
    Is it not the case that dependencies resolved via reflection would not require recompilation? This says nothing about whether the code will work or not, of course.
  37. Is it not the case that dependencies resolved via reflection would not require recompilation? This says nothing about whether the code will work or not, of course.
    You are of course right.. I think the question is what one expect as the usage scenario for the build tool. If you use it as your primary build tool during "ad-hoc" development and testing, you might consider your approach feasible. I usually use a tool like Eclipse for this purpose and use build scripts when I need to be sure that every dependency is actually satisfied, formal or informal. Thinking about the build process in (the otherwise excellent) NetBeans, I can understand sort of the frustration :-).
  38. A huge percentage of dependencies could be determined by static analysis. Basically, every compile error found by recompiling the entire source tree should be detectable without having to do so.
    Given that tools (e.g. Eclipse) can already determine static dependencies given a Java element, this seems undeniable. Actually, come to think of it, doesn't Eclipse already do this, at least to some degree? When I change some code and save, I see if that creates errors elsewhere almost immediately. And I know it's not the only tool that does this, I believe that other IDEs do better than that.
  39. A huge percentage of dependencies could be determined by static analysis. Basically, every compile error found by recompiling the entire source tree should be detectable without having to do so.


    Given that tools (e.g. Eclipse) can already determine static dependencies given a Java element, this seems undeniable. Actually, come to think of it, doesn't Eclipse already do this, at least to some degree? When I change some code and save, I see if that creates errors elsewhere almost immediately. And I know it's not the only tool that does this, I believe that other IDEs do better than that.
    I think the IDE examples is very helpful. As I understand this selective compile feature, it is not for building your production release where you need utmost reliability. Neither would you probably use it for the continuous integration machines. It is a development feature for shortening the debug cycles. And if it would really shorten a debug cycle for a particular project from minutes to seconds (as said above), that would be worth accepting some loss in reliability. The same is true for the IDE's. There is always the situation where you have to go for a 'rebuild all', where incremental compile did not work. But most of the time it does work. IntelliJ is doing this even for dynamic languages although a 'rebuild all' is required more frequently.
  40. A huge percentage of dependencies could be determined by static analysis. Basically, every compile error found by recompiling the entire source tree should be detectable without having to do so.


    Given that tools (e.g. Eclipse) can already determine static dependencies given a Java element, this seems undeniable. Actually, come to think of it, doesn't Eclipse already do this, at least to some degree? When I change some code and save, I see if that creates errors elsewhere almost immediately. And I know it's not the only tool that does this, I believe that other IDEs do better than that.


    I think the IDE examples is very helpful. As I understand this selective compile feature, it is not for building your production release where you need utmost reliability. Neither would you probably use it for the continuous integration machines. It is a development feature for shortening the debug cycles. And if it would really shorten a debug cycle for a particular project from minutes to seconds (as said above), that would be worth accepting some loss in reliability. The same is true for the IDE's. There is always the situation where you have to go for a 'rebuild all', where incremental compile did not work. But most of the time it does work. IntelliJ is doing this even for dynamic languages although a 'rebuild all' is required more frequently.
    Eclipse's selective compilation is not terribly reliable so that might account for it not being recommended for 'real' builds. The JLS clearly states what changes require recompilation of dependencies. Unless someone can point to a specific case where a dependency cannot be determined through static analysis (and I don't believe reflection is one) then I have to maintain that this is possible. As a simple thought experiment, if you use timestamps of the files (assume this is reliable), you can track down all the dependencies from the classes in that file recursively. For large codebases, I can imagine this might save some time although for smaller ones you may not see any benefit or even worse performance that just a straight full rebuild.
  41. Currently, there is no tool I am aware of that properly determines the dependencies between java class files and conditionally builds only (and all of!) what's needed. Neither ANT nor javac does this, and ANT's task routinely is unable to.
    Jikes used to be darn good at this. I remember moving from a homegrown javac/make build system to incremental builds with jikes and suddently 15 minute builds became 30 second builds. This was in 2001 though, and I havent used Jikes for a long time since.
  42. Currently, there is no tool I am aware of that properly determines the dependencies between java class files and conditionally builds only (and all of!) what's needed. Neither ANT nor javac does this, and ANT's task routinely is unable to.
    We used this in one of my previous projects: http://www.experimentalstuff.com/Technologies/JavaMake/index.html
  43. Currently, there is no tool I am aware of that properly determines the dependencies between java class files and conditionally builds only (and all of!) what's needed.
    Try Javamake from Sun experimental labs: http://www.experimentalstuff.com/Technologies/JavaMake/index.html When I used it a several years ago it seemed to deal with most class compilation dependencies, except for multiple top-level classes within a single source file (nested classes were ok). It provides an ant task that is similar to javac so it is simple to try in an existing ant build.
  44. Re: Gradle - A new Build System[ Go to top ]

    Was skeptical about another build tool but I'm impressed with the amount and quality of the documentation for a new open-source project. Also for the fact that you don't have to reinvent the wheel as far as repositories and dependency management go. Looks promising for when maven gets out of hand (multiple projects and weird dependancies - basically anytime you need to get off the maven rails).
  45. Re: Gradle - A new Build System[ Go to top ]

    Was skeptical about another build tool but I'm impressed with the amount and quality of the documentation for a new open-source project. Also for the fact that you don't have to reinvent the wheel as far as repositories and dependency management go.

    Looks promising for when maven gets out of hand (multiple projects and weird dependancies - basically anytime you need to get off the maven rails).
    Is this not the case for almost every slightly complex Maven build? This is the problem of frameworkitis ;) http://www.artima.com/lejava/articles/reuse3.html
  46. Re: Gradle - A new Build System[ Go to top ]

    I've wanted to move into a Groovy-based build environment for a while now, but didn't think Gant offered much beyond normal Ant capabilities with easier syntax - not much incentive to actually migrate any existing projects to Gant or spend time learning the differences. I have to say that I'm extremely impressed with what Gradle offers thus far, and even in its initial state, it looks fantastic. There are so many features that could make this a first-class citizen in an average developer's toolbox. And I must say I'm absolutely thrilled with Gradle's choice for Ivy integration, which is a gem in its own right. Ant+Ivy is our build environment of choice, so it would be a wonderful progression to move to Gradle, given how much I like Groovy. I'm definitely going to give this a try on my next project. I might even try to see how easy it is to supplant ant on my current open source project. Fantastic effort, please keep it up. The Java/Groovy community needs something like this! -- Les
  47. Re: Gradle - A new Build System[ Go to top ]

    I have to say that I'm extremely impressed with what Gradle offers thus far, and even in its initial state, it looks fantastic. There are so many features that could make this a first-class citizen in an average developer's toolbox.

    And I must say I'm absolutely thrilled with Gradle's choice for Ivy integration, which is a gem in its own right.
    I was solely using Maven2 for years. I just knew that Ivy existed and I thought it plays more or less in the same league as Maven's dependency management. I couldn't have been more wrong. I completely agree that Ivy is a true gem. Starting from the quality of the code base to the fantastic solution of the problem space of dependency management. And its getting better and better. If I had to choose now between Ant & Ivy or Maven, my decision would be very clear. Well, but now there is Gradle :) It adds one missing piece to Ivy. A build system that offers a build-by-convention integration for it. I've posted to the Ivy User list on how Gradle uses Ivy.
    Ant+Ivy is our build environment of choice, so it would be a wonderful progression to move to Gradle, given how much I like Groovy.

    I'm definitely going to give this a try on my next project. I might even try to see how easy it is to supplant ant on my current open source project.

    Fantastic effort, please keep it up. The Java/Groovy community needs something like this!

    --
    Les
    Thanks a lot for your feedback. I'm very happy that you like Gradle. Regarding the state of Gradle and using it right now. I've taken the decision a couple o months ago, that the first release should be close to being 'production ready' in terms of quality and functionality (not in terms of API stability). I think this is more or less the case.
  48. Re: Gradle - A new Build System[ Go to top ]

    To misquote Bono "But all the promises you made, From the Gradle to the Grave, When all I want is ${InsertFavouriteBuildToolNameHere}"
  49. granular build dependencies[ Go to top ]

    I really like at first glance what Gradle is doing. I cannot wait to download and try it out! In regards to granular dependencies, would adding JavaMake into the mix provide a solution for what some folks are asking for (i.e c/c++ make like dependency checking between source and header files)