On Fri, May 29, 2009 at 2:00 PM, Dean Schulze <[email protected]>wrote:
> > Ant's shortcomings aren't due to it's requiring you to specify how your > project is laid out. That is quick and easy. Ant's problems are due to it > being based on a markup language rather than a scripting or programming > language. One of Ant's problems is being based on a markup language. Another is that it is a scripting system (despite what Ant considers itself). This is not altogether bad, but it has led to Ant requiring that you say "how" the build should occur, instead of "what" the build should do. This is not very obvious, but I think it's critical, and one of the main reasons we went with Gradle. In Ant, I don't say "compile my classes" I say "use javac to compile classes from here and put them in there and do it this way and that way". Then, when I need to run tests, I have to say "use junit to run these classes from here and produce output there and use junitreport to make a nice report from there and put it here". But now I have stated my classes twice. Ant's solution is to use properties, but these are not very reusable (most of the time). With non-trivial builds this makes for a build system with lots of assumptions about what properties are what and how they are used. And this is very fragile. Gradle makes it possible for me to say "my classes are here", "my tests go here", and "my reports go here". Even better, if I follow standard conventions I don't even have to say that. Then, I can just say "compile my classes", or "run my tests" and Gradle knows how to do it. Even better, the Java plugin just knows to do it and I don't even have to say that. I can just say "use the java plugin" and I'm golden. Now, here is where I love Gradle: I can add more conventions for my project that special to it, and more logic around those conventions (using the buildSrc special module) and now I have a customized build system that knows my very special world! And I can have hundreds of subprojects that have simple "my stuff is here" build.gradle files. Try that with Ant!! > > I haven't used groovy very much, but it just seems like the right > foundation for a build tool. I haven't heard anything good about Maven, > though, and I'm skeptical about adopting it's conventions in a build system > that in large part was created to overcome the shortcomings of XML based > systems like Ant and Maven. > > Don't throw the baby out with the bath water! Maven had some good ideas (such as convention based builds). As a matter of fact, I have often stated that I love the ideas behind Maven, I just hate the implementation of those ideas. The basic "our way or the highway" approach of Maven is a major problem. The extreme difficulity adding new capability to Maven (ever tried writting a Maven plugin? I did, and it sucked!) is another major problem. But binary repositories are a good idea. Conventions that let the system do lots of stuff automatically are a good idea. Allowing plugins to extend the build system is a good idea. Gradle has just taken these good ideas and made them easy and powerful, whereas Maven made them clunky and complicated. Your main issue seems to be that Gradle decided to use the Maven conventions by default. Given the popularity of Maven (your personal experiences notwithstanding), I suspect that a lot of Gradle converts will come from Maven so this seems like a good idea. Also, a lot of thought was put into the Maven conventions, and this way the Gradle folks didn't have to do that brain damage all over again. But, like we've said, those conventions are easily overriddable (even in a project with hundreds of subprojects, I can just override them once) so I don't see a problem here. -- John Murph Automated Logic Research Team
