Le nouveau royaume de Eric Buist

Étiquette : Maven

  • Groovy + Maven + Eclipse = headache

    Java is a general-purpose programming language that matured over more than ten years. It provides a solid platform on which many third party libraries (of various quality and complexity of course) were developed. Maven is one of the several ways large Java projects can be described formally and built automatically. Maven has the ability to manage dependencies a lot better than the traditional way of bundling everything together in a large archive and aims at simplifying and unifying build process, although advanced configuration quickly drifts into XML nightmares. Then comes Eclipse, an integrated development environment. Although not perfect, very far from it, Eclipse has been a time saver for me, especially when comes time to search into large code bases and refactor code.  Eclipse is designed for Java, and it has a plugin to integrate well with Maven, called M2Eclipse. We can safely state that Java, Maven and Eclipse play well together.

    Then comes Groovy, a language built on top of Java. Source code in the Groovy language is compiled into byte-code like Java is, and the byte-code can run under the same virtual machine as regular Java programs, with the exception they need a set of runtime classes and the generated byte-code has some more indirections as compared to one generated by a traditional Java compiler. As a Java extension, we would expect Groovy to play well with Maven and Eclipse. Well in practice, I found out not to be exactly the case.

    I experienced what follows with Eclipse Kepler, Groovy 2.2 and Maven 3. Things may have been better with older versions or with newer ones, that will have to be seen.

    Groovy and Eclipse, almost well but…

    First time you will try to write a Groovy program in Eclipse, you will notice that there is absolutely no IDE support for that language. You won’t be able to use any code assist and Eclipse will not allow to compile or run Groovy code for you. You will need to install an extension to get Groovy support. This is the Groovy Eclipse plugin. The plugin works relatively well, but it has a couple of annoying drawbacks.

    First, code completion works in random erratic ways. I sometimes get tired and turn it off. For example, I had a variable of type String. I knew it was a String and the IDE had the ways to know, because I declared the type of the variable in my code. In Groovy, you can use variables without declaring the type. However, when I was trying to get proposed completions for to, I was getting toUpperCase() but not toLowerCase(). This was completely arbitrary.

    When running a Groovy script, the arguments in the launch configuration get prepopulated with a list of standard stuff that you must not delete. If you want to pass your own arguments to your script, you have to append them at the end of what the Groovy extension inserted in the Arguments box and you need to be careful not to delete the predefined stuff if you completely replace your custom arguments.

    Debugging Groovy code in Eclipse is like playing Russian roulette. Sometimes you can print the contents of a variable, sometimes you cannot; you don’t know when it will fail and why.  Sometimes you can expand an object and see its fields, sometimes the + icon is not there and you cannot expand, again for no obvious reasons. Execution may step into closures or may not, you don’t know, at least I didn’t. You can work around by putting breakpoints in the closures, but when you go out the closure, you end up in strange places of the execution within internals of Groovy. Conditional breakpoints never worked, at all, so I had to constantly pollute my code with insane if (some condition) println(« Bla ») and be careful to remove all the junk after I’m done debugging.

    Error messages are sometimes cryptic. If you are unlucky enough, you can even manage to get an Internal error from the Groovy Eclipse compiler! I was getting that in one of my classes and had to disable static type checking for that class to get rid of it.

    On Monday, August 4th 2014, things went completely south after I upgraded my build to Groovy 2.3. Everything was working fine with Maven on the command line. Eclipse was compiling the code fine. I set up the project to use Groovy 2.3 and there was no issue. However, when running the project, I was getting the following runtime error.

    Conflicting module versions. Module [groovy-all is loaded in version 2.2.1 and you are trying to load version 2.3.6

    I looked at my POM file, analyzed Maven dependencies with both mvn dependency:tree and Eclipse, found no Groovy artifact except the 2.3.6 one, verified my PATH to make sure only Groovy 2.3 was on it, checked Eclipse preferences many many times, restarted Eclipse several times, to no avail. There seems to be something in the Groovy Eclipse plugin hard-coded for Groovy 2.2, even if the compiler is set to 2.3!

    Any search on Google is yielding results about Grails and Spring, as if nobody is using Groovy alone anymore, only with other frameworks. Nobody else seems to be having the issue.

    Maven + Groovy = fire hazard!

    Maven relies on plugins to perform its tasks, so the ability to build something with Maven depends on the quality of the plugins. There is unfortunately no official well known, well tested and stable plugin to build Groovy stuff using Maven. The page Choosing your build tool gives a good idea of what is currently available.

    First I read about GMaven, but I quickly learned it was not maintained anymore, so I didn’t try to use it. Then I read that the Groovy Eclipse Compiler was the recommended one. I was a bit reluctant, thinking this was a piece of hackery that would pull out a bunch of dependencies from Eclipse, resulting to an heavy weight solution. But this was in fact well isolated and just the compiler, no need to pull the whole Eclipse core!

    Maven Eclipse compiler worked well a couple of months for me. However, yesterday, things went south all of a sudden. First, there were compilation errors in my project that would not show up into Eclipse but appeared when compiling with Maven. These were error messages related to the static type checking. After fixing these, compilation went well, but all of a sudden, at runtime, I was getting a ClassNotFondError about ShortTypeHandling. I read that this class was introduced by Groovy 2.3 while my project was using Groovy 2.2. Digging further, it seemed that the Groovy Eclipse Compiler was pulling Groovy 2.3, compiling code against it but the code was executed with Groovy 2.2. This should in principle not cause any problem, but it seems that in Groovy, byte-code is not fully compatible between versions!

    I tried updating my dependency to the Groovy Eclipse Compiler in the hope that would fix the issue. However, that changed my ShortTypeHandling exception for stack overflows. It happened that the clone() method of one of my class was calling super.clone(), which is perfectly normal. But Groovy was making something nasty that was causing super.clone() to recursively call clone() of my subclass! This resulted to an infinite loop causing the stack overflow.

    I found this issue to be even more intricate after I tried to compile my code on JDK8 and found it out to be working correctly. In other words, the JDK was affecting how Groovy Eclipse Compiler was building the byte-code!!! In JDK7, something would fluke the byte-code, causing the stack overflow errors, while in JDK8, everything would go fine!

    I then tried updating the compiler once more, to the latest and greatest. Things compiled, but I was back at square one with the ShortTypeHandling exception! So no matter what I was trying, Maven was unable to build the project anymore.

    I was about to give up on Maven and use a batch file to call Groovy directly, but that would have been a lot of fiddling with the class path. I was not happy at all about this solution.

    Then I found out about the GMavenPlus plugin. I tried it and it worked like a charm! The plugin makes use of the Groovy artifact defined in the project’s dependencies rather than hard-coding a compiler for its own version of Groovy. It uses the official Groovy compiler API rather than its own, so things get compiled the same way as when using the Groovy Ant task or the standalone groovyc compiler. GMavenPlus saved my day yesterday, freeing me from a lot of hassle.

    Is it worth it?

    I’m not sure at all. I got several problems with Groovy that would deserve a separate post. The integration difficulties with Maven and Eclipse make me believe it is better just to use Java directly. JDK8 introduced lambda expressions that fulfill a part of what Groovy is trying to implement in its own special way. For projects that really need a true scripting language, there are already several of them, like Python, which is built from the basis for scripting.

  • Groovy? Pas sûr…

    Hier, je me suis dit que ça vaudrait la peine d’essayer d’utiliser le langage de programmation Groovy pour un projet chez Nuance. J’estime que cela va me permettre de générer et manipuler du XML plus facilement et m’éviter de répétitives constructions. Plutôt qu’écrire du code pour effectuer la même opération sur chaque item d’une liste, classifier des items selon certains critères afin de pouvoir appliquer un traitement spécifique à chaque classe d’items, ouvrir des fichiers, etc., je pourrai me concentrer davantage sur la logique du programme et éviter de perdre plein de temps à écrire de la poutine répétitive et déboguer. Eh bien pour le moment, c’est exactement tout le contraire! Voici pourquoi.

    • Cette journée a mal commencé avec un problème de connexion de mon écran. Mon laptop de Nuance est relié chez moi à mon écran par un adaptateur mini-HDMI vers HDMI, un fil HDMI qui va dans un commutateur HDMI, puis un fil HDMI vers DVI qui va dans l’écran. Eh bien je n’avais plus d’image. Pourtant, mon ordinateur personnel, lui aussi raccordé au commutateur et allumé pour des raisons qui importent peu ici, affichait le bureau d’Ubuntu. C’est arrivé à quelques reprises et j’ai dû débrancher et rebrancher le câble mini-HDMI. Eh bien en vain cette fois. Cela a fini par fonctionner en essayant avec un autre adaptateur mini-HDMI! Je ne sais pas encore si c’est vraiment l’adaptateur, car mon Raspberry Pi a aussi, hier soir, refusé d’afficher en HDMI. C’est donc peut-être le foutu commutateur si bien qu’il faudrait idéalement que je remplace mon écran par un doté de plusieurs entrées HDMI. Mais les écrans d’ordinateur ont pour la plupart une seule entrée DVI ou HDMI.
    • L’installation de mon environnement Groovy a posé des difficultés. Je n’ai eu aucun mal à installer Groovy lui-même, à mettre en place le plugin Groovy pour Eclipse, mais après, les problèmes ont commencé. Je me suis vite rendu compte qu’il valait mieux créer un nouveau projet distinct dans Eclipse pour cette nouvelle tâche, pas seulement pour éviter d’introduire des difficultés dans les builds à cause de Groovy mais aussi par souci de séparation correcte du code. Sans cela, Eclipse indiquait que le compilateur Groovy du projet, dicté par le fichier POM de Maven, ne correspondait pas au compilateur utilisé par défaut dans Eclipse. Il fallait alors modifier les propriétés du build, dans Eclipse, et il n’y avait pas de synchronisation avec le fichier POM de Maven, donc modifier le fichier POM risquait de nécessiter de refaire le paramétrage du build, et toute personne désireuse de consulter mon code dans Eclipse aurait elle aussi à paramétrer le build.
    • Trouver comment configurer mon fichier POM pour que Maven puisse gérer mon satané projet Groovy n’a pas été une mince affaire. Le plugin GMaven qui semblait devoir faire ce travail est discontinué, sans aucune alternative convainquante pour le remplacer! Le seul candidat est un plugin Groovy-Eclipse-Compiler qui me semble un joli hack utilisant le compilateur d’Eclipse en arrière-plan pour compiler du Groovy! Mais bon, c’est tout ce qu’on a alors on essaie. Eh bien il me fallut copier/coller plusieurs blocs de code dans mon fichier POM et ça ne fonctionnait même pas pour les raisons suivantes!
    • Eclipse s’est d’abord plaint qu’il y avait deux installations de Groovy dans le classpath. J’ai dû exclure celle en provenance d’un projet dépendant; c’était la 1.8 et je voulais partir avec la 2.0. Après, eh bien encore cette erreur de correspondance du compilateur: mon projet voulait Groovy 2.1, Eclipse avait la 2.0! Il m’a fallu utiliser une version antérieure de Groovy-Eclipse-Compiler, et trouver le bon numéro de version a demandé des recherches à plus finir.
    • Après tous ces efforts, eh bien Eclipse est devenu affreusement lent et gelait à tout bout de champ. Cela a fini par des erreurs à propos de mémoire insuffisante puis un plantage. Par chance, le comportement était plus normal après le redémarrage d’Eclipse.
    • Ensuite, le développement a véritablement commencé. D’abord, le plugin Groovy d’Eclipse souffre de problèmes lorsque vient le temps de proposer des noms de classes, méthodes et propriétés. Parfois, il trouve un nom, parfois pas, et c’est très arbitraire. Par exemple, j’avais une variable de type String (chaîne de caractères), et Groovy avait l’information à propos du type (à noter que ce n’est pas toujours le cas vu la nature dynamique de Groovy). Eh bien Eclipse localisait la méthode toLowerCase() mais pas toUpperCase()! La complétion de noms de classes fonctionnait parfois, mais elle n’ajoutait pas toujours l’importation nécessaire si bien qu’après coup, j’avais des erreurs indiquant que la classe récemment référencée n’était pas trouvable, devais sélectionner sa référence et appuyer sur CTRL-SHIFT-M pour ajouter l’importation. Ça fonctionnait parfois, parfois pas, il fallait alors appuyer plusieurs fois!
    • D’autres difficultés surgirent en raison de ma connaissance embryonnaire du langage Groovy. Par exemple, je me suis emmêlé les pinceux avec la notation pour construire un tableau associatif. Il ne faut pas utiliser [a:b, c:d]; ça ne va pas fonctionner, le compilateur va se plaindre de l’absence des variables b et d. Il faut plutôt utiliser [a: »b », c: »d »] ou encore [« a »: »b », « c »: »d »]. Mais pourtant, GroovySH va bêtement afficher [a:b, c:d] si on lui demande de montrer le tableau! Déclarer une variable de type List<?> ne fonctionnait pas: il fallait que j’utilise simplement List; en Java, cela déclenche un avertissement comme quoi c’est un type brut. Mais si je déclarais List[] ou List<?>[], eh bien j’avais un avertissement à propos du type brut! Il faut utiliser des listes au lieu des tableaux ou bien ne pas déclarer de type du tout. Mais je trouve ça plus clair de donner le type, surtout pour les arguments d’une fonction!
    • J’ai été bien choqué quand j’ai voulu créer une classe avec des champs et y générer des accesseurs, car la fonction d’Eclipse pour le faire n’était pas disponible en Groovy. Je me suis alors rappelé qu’il existe des annotations pour indiquer à Groovy de générer ces accesseurs automatiquement. Eh bien je n’arrivais pas à retrouver ces annotations dans la documentation et des recherches sur Internet me donnèrent à des indices pour bâtir une transformation d’AST personnalisée permettant de le faire!!! Bon sang! Par chance, il suffisait de déclarer mes champs sans modificateur d’accès pour que Groovy ait l’intelligence de les traiter comme des propriétés et alors définir les accesseurs.
    • Outre les problèmes syntaxiques, il y a aussi eu des difficultés d’API. Jusqu’à ce que je trouve la documentation du GDK, indiquant quelles méthodes Groovy ajoute à Java, je n’arrivais pas à savoir facilement comment appliquer une transformation sur tous les items d’une liste (collect peut le faire), s’il était possible d’ouvrir un fichier texte en UTF-8 avec un seul appel de méthode plutôt que construire le FileInputStream, puis le InputStreamReader, et enfin le BufferedReader, etc..
    • J’ai aussi eu des difficultés avec le débogueur qui s’est remis à se plaindre chaque fois que je définissais un point d’arrêt conditionnel. J’avais beau vérifier et revérifier l’expression de la condition, tout était OK. Pourtant, j’avais cette maudite erreur. J’ai encore été obligé de modifier le code temporairement après quoi le point d’arrêt fonctionnait, mais Eclipse n’arrivait pas à trouver le code source de la classe, dans un projet importé par dépendance Maven qui était pourtant dans mon espace de travail Eclipse! Il m’a fallu indiquer l’emplacement explicitement puis j’ai enfin pu déboguer le code. C’est possible que ce soit ça qui ait brisé les points d’arrêt conditionnels.
    • J’ai eu des erreurs d’exécution à la pelle! Le code compilait, semblait beau, mais à l’exécution, j’avais des problèmes à propos de méthodes ou de propriétés inexistantes. Cette fois-ci, ce n’était pas Groovy, ni Maven, ni Eclipse mais bien mon code; il fallait corriger les petites erreurs. Certaines erreurs ont été difficiles à corriger, surtout celles qui ont surgi quand je me suis mis à utiliser le MarkupBuilder de façon un peu exotique pour construire mon XML de façon dynamique. Oh là là! La documentation de Groovy n’explique pas très bien comment fonctionne le builder; c’est un fichier en progression. Mais pourquoi placer une page sur un site web pour simplement écrire, pendant deux ans, work in progress ou coming soon? Je ne me souviens plus exactement d’où j’ai eu les indices pour comprendre ce qui se passe, peut-être dans le chapitre sur les DSL de Groovy in Action. Le problème ici était que mon fichier XML n’était pas statique: je devais générer un élément <task> pour chaque tâche de mon application et y injecter des attributs au besoin, pas toujours tous les attributs! Par chance, la chose a été possible et peut être étendue pratiquement à l’infini.

    En bref, quelle galère! On se demandera si tout ceci a valu le coup. Je me le demande moi aussi. Je pense que l’apprentissage de Groovy aura une utilité si bien que je prévois continuer cette exploration. Je ne saurais pour le moment mesurer la contribution exacte de Groovy, Eclipse et Maven dans cette expérience plutôt déplaisante.

    Il faut garder à l’esprit que j’ai eu beaucoup de difficultés avec Eclipse, incluant des problèmes avec la complétion de noms de classes et de méthodes, les points d’arrêt conditionnels qui boguent parfois mais au moins pas de plantages, pas sous Windows en tout cas. Sous Linux, j’en ai déjà eu à plus finir. Pourtant, les alternatives à Eclipse sont plutôt limitées: NetBeans qui ne gère même pas bien le fichier POM de notre projet chez Nuance, IntelliJ dont la version gratuite est bridée (on ne sait JAMAIS quand on tombera sur un blocage demandant la version payante!!!) et puis les éditeurs de texte comme Notepad++, Emacs, Vi, etc. Ces éditeurs sont excellents, je ne peux que l’avouer, mais ils ne suffisent pas à la tâche pour gérer un gros projet Java ou Groovy avec plusieurs classes.