Cher lecteur du Touilleur Express. Après avoir publié comme tu le sais de nombreuses fois à 2h du matin pour que tu aies ton numéro du Touilleur à lire au petit matin, sache que j’ai un nouveau concept à te présenter. J’ai assisté à la présentation qui va avoir lieu ce jeudi à Paris chez Zenika. Et donc tu peux soit attendre jeudi et te faire ta propre opinion, soit lire et voir tout le mal que je pense du speaker. Note que je viens de spoiler un peu… mince.
Alors sur le fond tout d’abord, je garde la forme pour la suite. Hans Dockter est le responsable du projet Gradle, un ancien commiter de JBoss IDE, et un formateur chez Skill Matters. La présentation sera animée, avec du code et un exemple intéressant à suivre.
Tout d’abord la première question : pourquoi Gradle ?
Ah il y a une autre question avant dans la salle : c’est quoi Gradle ?
Gradle est un système de build écrit en Groovy qui permet de construire une application, de la packager, de gérer les releases, la version sur le repository du code source, bref de faire ce que fait Ant/Maven. Il utilise d’ailleurs les dépendances de Maven sans problèmes (qui a dit « pas comme maven » ?)
Hans Dockter a présenté Gradle en axant dans sa première partie les défauts des autres outils comme Ant ou Maven. Là où il a tout à fait raison, c’est que Ant est bien trop simple. Il demande ainsi à la salle si nous avons une idée du nombre d’éléments de la DTD d’un script Ant ? la réponse est 5 : Tasks, Properties, et j’ai oublié les 3 autres… Bref cela fait que pour des tâches répétitives, il faut systématiquement définir ses tâches, comme JUnit. Bon ok.
Gradle vise à rendre l’impossible, possible. A rendre le possible -> facile. Et le facile -> élégant. Il explique que le modèle des scripts Ant date des années 97-2000, que depuis nous avons besoin d’une solution plus souple. Alors ensuite Maven.
Maven 2 offre beaucoup de fonctionnalités supplémentaires, voir peut-être trop d’après lui. Le support des plugins, des dépendances transitives, le build-by convention, bref tout ceci fait que Maven est plutôt un bon système. Il reproche simplement la verbosité du XML, le fait qu’il soit difficile de n’exécuter que certaines tâches, la complexité de certains plugins, le manque de consolidation dans la manière de gérer et configurer les plugins, bref trois fois rien…
Alors arrive Gradle. A cet instant de la présentation cher lecteur, je suis un peu dubitatif. J’ai horreur des gens qui vendent un médicament en critiquant les autres médicaments au lieu de parler de la maladie. J’étais donc assez fatigué d’entendre depuis 15mn du vent sur « Ant il est tout pourri » et « Maven nous emmène jamais au heaven« … A ma gauche j’ai quand même Vincent Massol de XWiki, l’un des CastCodeurs, mais surtout l’un des auteurs de Maven: A Developer’s Notebook, livre à lire d’urgence. Et je sens que Vincent n’est pas traversé par le saint-esprit de Gradle. Je me trompe Vincent ?
Hans Docket ouvre (enfin) son IDE favori (IDEA IntelliJ) sur sa machine favorite (Mac Book Pro) et il est temps de voir la tête d’un script Gradle.
task hello < < {
println 'Hello world!'
}
Après avoir défini une "task", comme il l'explique rapidement : un script Gradle est un script... Groovy. Cela donne accès à toute l'API, ce que je trouve bien. Disons que vous souhaitez afficher l'heure dans votre build, nul besoin d'écrire un quelconque plugin, un simple println ladate et c'est tout.
La gestion des dépendances entre Task est limpide :
task hello < < {
println 'Hello world!'
}
task intro(dependsOn: hello) << {
println "I'm Gradle from Jazoon"
}
Si j'exécute ce code voici ce que cela donne :
> gradle -q intro Hello world! I'm Gradle from Jazoon
Prenons ensuite un script build.gradle complet pour vous montrer ce que cela donne :
usePlugin 'java'
sourceCompatibility = 1.5
version = '1.0'
manifest.mainAttributes(
'Implementation-Title': 'Gradle Quickstart',
'Implementation-Version': version
)
repositories {
mavenCentral()
}
dependencies {
compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
testCompile group: 'junit', name: 'junit', version: '4.+'
}
test {
options.systemProperties['property'] = 'value'
}
uploadArchives {
repositories {
flatDir(dirs: file('repos'))
}
}
On est d’accord pour dire que c’est clairement moins verbeux qu’un script Ant ou Maven.
Simple et efficace.
Par la suite il explique que Gradle est construit par Gradle, que la documentation par exemple est testée. Les exemples de code qui sont dans le manuel de Gradle sont testés par Gradle ! La documentation est ainsi mise à jour sur le site Internet de Gradle automatiquement, la classe non ?
La critique, la critique, la critique
Sans langue de bois : mauvais speaker. Un peu fouillis, on sens que Gradle vaut le coup d’être regardé mais ce n’est pas la bonne personne pour en parler. Les exemples de scripts m’ont donné cependant envie d’y jeter un oeil, et il a de bons arguments intéressants… mais bon, voilà.
Du côté de Gradle lui-même j’ai un truc qui ne m’a pas plus : la lenteur. Son script HelloWorld démarre poussivement en 2 secondes. Désolé mais mon système de build doit être rapide. Si je vois que ce système qui me fait remplacer 1 fichier pom.xml de 60 lignes par un script de 20 lignes multiplie par 3 le temps de compilation : poubelle.
Allez voir jeudi soir la présentation chez Zenika, et prenez une autre opinion que la mienne, qui est très personnelle. On est sur un blog personnel, je peux largement me planter, mais je ne crois pas à Gradle pour l’instant.
0 no like
Gradle peut effectivement utiliser les dépendances de Maven. Un des atouts de Maven aujourd’hui, c’est l’existence des repository Maven agrégeant tous les artefacts open-source et leurs descripteurs Maven contenant les dépendances transitives. Mais plus précisément, c’est grâce au système de gestion de dépendances Apache Ivy que Gradle peut lire et écrire dans un repository Maven.
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
My French is unfortunately not good enough to reply in French. So I hope nobody minds that I answer in English.
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
Hi everyone,
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