Rossi Oddet

Blog d'un artisan développeur

Soirée Devoxx France 2014 Au JUG Nantes

Ce mardi 20 mai, c’était soirée Devoxx France avec le JUG Nantes.

Le contenu :

Tour d’horizon de Devoxx France 2014

Thibaud et Pierre ont fait un résumé de leurs parcours Devoxx, donné leurs avis sur différentes sessions.

Ils ont identifié 4 thèmes principaux : Java 8, Javascript, Docker et Big Data. Les Keynote ne les ont pas vraiment marqué.

Thibaud et Pierre ont noté quelques sessions.

Est notée 4/4 :

Sont notées 3/4 :

Sont notées 2/4 :

Le bilan Devoxx ?

Après Devoxx France, on est motivé, on repart avec plein d’idées et des trucs à tester.

Thibaud Raison et Pierre Cosson au JUG Nantes

Et l’année prochaine ?

Devoxx France 2015 ça sera du 8 au 10 avril au Palais des Congrès. 1800 personnes sont attendues.

Thibaud et Pierre mettront à disposition leurs slides sur le site du JUG Nantes très prochainement.

Un petit mot sur Maven avant d’aborder la session de Cédric

Jusqu’à l’année dernière, je ne prenais pas très au sérieux les alternatives à Maven. En effet, Maven est un des super-héros du développeur Java.

Il a encouragé :

  • La modularisation. Les projets sont devenus de plus en plus modulaires.
  • Une normalisation (organisation des répertoires, cycle de vie d’un build, exécution des tests, etc.)
  • Un essor de l’intégration continue

Au regard de tous ces services rendus, beaucoup de développeurs Java sont très attachés à Maven et sont donc beaucoup moins réceptifs aux alternatives. J’étais un de ces développeurs. Ca fait presque 8 ans que j’utilise Maven et presque autant de temps à en dire du bien. J’ai même fait de la promotion en Afrique lors de JCertif 2012.

Il y a 3 ans, lorsque Grégory Boissinot présentait Gradle à ce même JUG Nantes. Je n’étais pas réceptif et en plus le projet manquait de stabilité (modification trop fréquente de l’API).

Je me disais :

C’est quoi cette chose qui ne veut pas rentrer dans le standard !

Je m’imaginais dans l’armée et je voyais les personnes qui faisaient autre chose comme des déserteurs.

J’étais allergique aux alternatives à Maven parce qu’elles :

  • donnaient de la flexibilité au standard Maven. Je me disais : Flexibilité = Entorse à la Norme = Désordre = Instabilité = Déserteurs :)
  • pouvaient utiliser des langages dynamiques. J’estimais perdre en lisibilité et du temps à apprendre un nouveau langage.
  • avaient une communauté restreinte et donc peu de plugins, réponses StackOverflow, etc.

Avec l’émergence des technologies frontend, des langages fonctionnels, des langages dynamiques, j’ai eu l’occasion de voir d’autres systèmes de Build (Gradle, Grunt, SBT, Gant, etc.). Et Maven me parait, désormais, vieilli face à ses concurrents.

Le projet Gradle a bonne presse en ce moment. Il a été bien aidé par des projets comme Hibernate qui l’a adopté. L’année dernière, Google l’a choisi comme système de build pour Android Studio.

C’est donc en mode réceptif que j’ai participé à la session de Cédric.

Gradle ne fait pas que remplacer Maven

Je vous invite à parcourir les slides de Cédric qui se lisent bien.

Parmi tous les avantages de Gradle par rapport à Maven, deux choses m’ont interpellé :

  • Le Wrapper. Pour un projet donné, vous pouvez générer un wrapper (gradle init) qui permettre à tous les utilisateurs de récupérer la version de Gradle à utiliser pour le projet. C’est particulièrement pratique pour l’intégration continue et aussi pour changer de version de gradle d’un projet. Cela permet aussi de faire cohabiter simplement différentes versions de l’outil de build chez un développeur.

  • Pour réutiliser de la configuration de Build, Maven utilise l’héritage et Gradle utilise la composition. C’est sur des points comme celui là que Maven montre sa vieillesse. Il a été conçu à une époque où l’héritage était le roi pour mutualiser du code. Les choses ont changé depuis… mais pas Maven…

Une chose est sûre, pour passer de Maven à Gradle, il faut apprendre Gradle. Maven a ses défauts qui sont connus et maitrisés. Il n’y a aujourd’hui aucune surprise à démarrer un projet avec Maven. Est-ce que les experts Maven sont prêts à prendre des risques ? Apprendre une nouvelle technologie alors que Maven fonctionne ?

Noter l’existence du projet Maven Polyglot qui va permettre de faire de la configuration Maven avec plusieurs langages : clojure, ruby, scala, yaml, et même Groovy :) Est-ce une réponse suffisante ?

Comments