Since I was mentioned in the main post and in a comment let me explain how I perceived the gradle presentation.

First I’m always curious about new stuff and I’m really happy to see people trying to innovate. It’s also good for maven to have competition.

I liked what I’ve seen and I think gradle is really an Ant++ build tool. It has the same concept as Ant, i.e. you define what your build should do in the script but with more powerful features since you have access to all Groovy features (and Java features).

When Maven was created the idea was that we all had created Ant scripts for several projects and we were always doing lots of copy paste between projects. I remember one project where I had 30 modules of 1000 Ant script lines in each (30K of build scripts in total). It was a pain to maintain and more than 80% were the same.

Thus the idea of Maven is to remove the idea of describing the build tasks to execute and instead describe your projects (data config). Maven1 was a failure in that sense since it allowed jelly to be used and people started using it in earnest to do whatever they wanted to do. Hence every maven project was different and hard to understand, use and maintain.

Maven2 improved on this by making it hard to extend it and thus you really really needed to perform custom stuff to want to write a plugin. As a consequence the plugins improved and offered more configuration options as time progressed. This allowed to have maven builds that are very similar across projects thus realizing the initial goal of maven. It’s quite easy to understand a maven2 build right now and to maintain it.

Now Maven3 will build on this while making it slightly easier to extend in several aspects as presented by Jason at Jazoon.

Back to Gradle. It’ll have to go through the same challenges as Maven went through in order to provide a common DSL used by all and strong plugins used by everyone. If this is not achieved then gradle will remain a more powerful Ant (which is already a nice place to be ). My worry for Gradle is that it’s very powerful and people will likely abuse this power, making maintenance a pain.

I’m curious to see how gradle will progress:
- as the » assembly language » equivalent for builds
- as powerful and *standard* DSLs for specific build domains (thus going in the same direction as Maven).

In any case, well done Hans. This is a very nice project with lots of potential.

-Vincent

When I’ve read your posting I was sometimes wondering if we really attended the same presentation.

You say (Google Translation): At this moment of the presentation dear reader, I am a little dubious. I hate people who sell a drug by criticizing other drugs instead of talking about the disease. So I was quite tired of hearing from 15mn wind on « Ant it is rotted and Maven never takes us to heaven »

I completely disagree that this is what I have said. I have taken a look at Ant and Maven and talked about it’s respective good and bad qualities. In regard to Ant I really like the fact that it is a flexible language. What is missing are higher abstractions for Software projects. What I like about Maven is that it introduces the higher abstractions. What I very much dislike about Maven is that it provides a big rigid framework to provided them. I’ve talked a about the conceptual problems of Maven and that the fact that it is based on XML is only a minor issue. I don’t know how you can have missed this.
You are also saying that all the goodies of Maven might be to overwhelming to me. This is another comment that surprises me. I have talked about Gradle’s more flexible transitive dependency management and the fact that Maven’s convention-over-configuration is often a convention instead of configuration mechanism. Gradle of course also offer build-by-convention, as I have in shown in my Java live demo during the presentation.

In regard to start up time. Gradle caches the compiled build scripts. So as soon as you execute an unchanged build script a second time start up time will be faster. You might give this a try. Our start up time for a hello world script is to 99 percent Groovy start up time. We have switched recently from Groovy 1.5 to Groovy 1.6 and 1.6 has a higher startup time (which enables Groovy to have a better execution performance). I hope Groovy can improve here in the future. Another alternative we are thinking about is having a pre initialized JVM running in the background. I also would like to note that Groovy still has the best startup time compared to Scala and JRuby. But as Gregor has pointed out, the true performance is the overall execution time for a build. And even for a simple build we are usually as fast or faster than Maven.

I’m sorry that you did not like my presentation style nor the structure of the presentation. But most of the arguments you have given in your posting do not convince me. I have to say that I find them mostly cheap and superficial. They don’t provide a base for a decent discussion.

I hope there will be a decent discussion during and after the Zenika presentation. I’m looking forward to this event.

- Hans

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

Ensuite, je ne suis pas étonné qu’une personne comme Vincent Massol soit retissant à Gradle. Rien de plus normal en regard de son passé.

Concernant les performances de Gradle, les lecteurs peuvent suivre cette question sur la mailing list de Gradle
http://www.nabble.com/Gradle-performance-td23806096.html

Comparé au builder Ant, le temps d’exécution peut effectivement paraître poussif pour de petits scripts Gradle. Mais il ne faut confondre le temps d’initialisation du lancement de Gradle et le temps total d’exécution du script. Ce temps devient plus insignifiant sur une chaîne de build plus complète. Et n’oublions pas que c’est du Groovy derrière. Mais dans tous les cas, c’est un axe d’amélioration dans les prochaines versions de Gradle.

Enfin, je suis étonné que Hans n’a pas insisté sur la flexibilité de Gradle en comparaison de Maven, la réutilisation native de toute tache Ant et l’utilisation possible du système de build Gradle comme complément dans une infrastructure Maven existante ; au lieu de le présenter uniquement comme un builder alternatif.

–
Gregory Boissinot