D’abord il faut un besoin

Eh oui, parce que se contenter de créer un plugin qui affiche “Hello World” à chaque build, c’est pas très utile… Alors tant qu’à faire, mettons nous en situation réelle. J’aurais pu prendre comme exemple un plugin qui lance l’Annotation Processing Tool à chaque compilation (par exemple pour Android Annotations), mais je vais plutôt vous parler du premier plugin que j’ai eu à développer, qui permet de faire de la génération de code.

Ce générateur prend en entrée un modèle décrit dans un fichier XML, et produit en sortie des classes Java correspondant aux entités et aux DAO CRUD, ainsi qu’un script SQL de création de tables. Ces classes sont ensuite utilisables dans les services écrits à la main. Certaines parties du code généré sont configurables :

• le fichier XML décrivant le modèle
• le package Java de base des classes générées
• le nom du script SQL de créations de tables

Création du squelette de plugin Maven

Un plugin Maven n’est rien d’autre qu’un projet Maven avec un packaging de type maven-plugin :

La convention veut que les plugins soient nommés xyz-maven-plugin, ce qui permet d’appeler les goals de la manière suivante lors d’un build :

Notez qu’il n’est pas nécessaire de spécifier le nom complet du plugin, Maven va compléter avec “-maven-plugin”, ça fait quelques caractères en moins à écrire . Si la convention de nommage n’est pas suivie, il faut impérativement spécifier le nom complet du plugin dans la ligne de commande.

Ensuite, un plugin contient un ou plusieurs MOJO, qui vont exécuter le “vrai” code du plugin. Un MOJO correspond en fait à un goal. Par exemple, dans le plugin dependency-maven-plugin, on retrouve les goals “tree” (mvn dependency:tree) et “resolve” (mvn dependency:resolve)

Créons donc un squelette de MOJO pour notre générateur de code :

Notre MOJO étend AbstractMojo, qui fournit toute l’infrastructure utile à la création d’un goal. La méthode abstraite execute() contient le code à exécuter, c’est donc à nous de l’implémenter. Pour l’instant elle ajoute une ligne de log saluant le monde (je sais, j’ai dit tout à l’heure qu’on ne se contenterait pas de faire un hello world…). La méthode getLog() est un exemple de facilités fournies par l’AbstractMojo.

Notez également la Javadoc, qui contient deux tags particuliers. @goal spécifie le nom du goal correspondant à notre MOJO, ce tag est obligatoire. @phase permet de dire à Maven que notre plugin intervient durant la phase de génération des sources du lifecycle Maven (avant la compilation des sources, donc).

Notre plugin est prêt à être exécuté. Configurons le pom.xml pour permettre l’exécution du plugin lors du build :

Puis lançons un build Maven :

Ajout de paramètres au plugin

Notre cahier des charges requière la possibilité de configurer certaines parties du générateur. Pour cela, ajoutons des paramètres à notre MOJO:

Nos trois attributs utilisent également des tags Javadoc pour indiquer que ce sont des paramètres du plugin. Les deux premiers sont obligatoires, le troisième est facultatif et prend une valeur par défaut. ${project.build.directory} sera remplacé au runtime par le chemin du dossier target.
L’attribut “alias” de @parameter permet de définir le nom du paramètre s’il est différent du nom de l’attribut Java. Ainsi, par défaut il y aura un paramètre nommé “basePackageName”, puisqu’on ne lui a pas donné d’alias. Une liste plus exhaustive des tags Javadoc est disponible sur le site de Sonatype.

Ouvrons à nouveau le pom.xml pour ajouter la configuration du plugin :

Pour vérifier que la configuration est bien injectée au runtime, ajoutons un log :

Maintenant que nous savons créer, configurer et exécuter un plugin Maven, il ne reste plus qu’à implémenter la méthode execute() pour appeler les vraies classes de génération de code. Comme ce n’est pas vraiment l’objet de cet article, je ne détaillerai pas plus cette partie. Cependant un FakeGenerator est disponibles dans les sources complètes.

J’aime pas les XDoclet !!

Comme vous l’avez vu, la configuration du Mojo se fait par défaut dans des tags Javadoc (des sortes de XDoclet). Ce n’est pas terrible dans la mesure où il est facile de faire une faute de frappe (ex @paramter au lieu de @parameter) qui ne sera pas détectée par le compilateur ni par Maven. Pour pallier ce problème, il existe un set d’annotations Java, le maven-plugin-anno. Après avoir configuré la dépendance dans votre pom, il est ensuite possible de tout annoter :

Sachez également que le support des annotations est en train d’arriver nativement dans Maven (Java5 annotations support for Maven plugins).

Conclusion

Comme vous avez pu le voir, créer un plugin Maven n’est pas très compliqué. Les plugins sont suffisamment souples et configurables pour pouvoir exécuter du code déjà existant (par exemple remplacer un main() par un plugin Maven) sans trop de difficultés. La palette de plugins déjà disponibles est assez vaste, mais si un jour vous avez un besoin spécifique vous saurez que le coût de création d’un plugin n’est pas très élevé .

Liens utiles

• Les sources complètes du code de cet article
• Introduction to Maven 2.0 Plugin Development
• Maven: The Complete Reference – Chapter 11. Writing Plugins

Un petit avertissement au passage : cet article suppose un minimum de familiarité avec Git.

Git-SVN c’est quoi ?

Git-SVN est un ensemble de scripts qui permettent d’utiliser un repository Git local, et de le synchroniser avec un repository central Subversion. Malgré quelques limitations inhérentes à Subversion, on peut alors profiter de l’essentiel des fonctionnalités de Git, tout en gardant cette utilisation transparente pour les autres personnes de l’équipe, qui peuvent continuer à utiliser SVN comme avant.
Le but de cet article, plus que de présenter les 3 ou 4 commandes à connaître pour utiliser Git-SVN, sera de faire découvrir l’outil,  de comprendre son fonctionnement, et de bien saisir quelles sont les limites de son utilisation (et il y en a).
Pour plus de détails sur son utilisation, il y a la doc !

Avertissement

Si vous avez le choix, utilisez plutôt Git. Vraiment. Git-SVN a beau être un gros pas en avant par rapport à Subversion, ça reste une façade qui ne parviendra pas à masquer toutes les imperfections de Subversion, et qui ajoutera d’autres problématiques à prendre en compte.

Bon on y va maintenant ?

Les avertissements d’usage étant exprimés, on va maintenant passer à la pratique.
On va partir du principe que le point de départ est un projet Subversion existant, avec lequel on va s’interfacer avec Git. Si vous partez sur un nouveau projet, utilisez Git directement.

Installation

Git-SVN s’installe de la même façon que vous avez installé Git… Pour la plupart des distributions Linux, ou pour Cywin, installez le package git-svn.

Initialisation

On part d’un dossier vide, et on va créer un nouveau repository local Git, synchronisé avec le serveur SVN :

Cette commande initialise un repository git vide, et ajoute les méta-données qui permettront de retrouver le serveur SVN pour se synchroniser.
Le paramètre -s indique que le repository SVN a une structure standard : trunk dans le sous-dossier trunk, branches dans branches et tags dans tags. Si ce n’est pas le cas, on peut remplacer le -s par -T, -b et -t pour indiquer respectivement l’emplacement du trunk, des branches et des tags. Les paramètres de ces commandes sont des dossiers, soit relatifs au repository SVN, soit absolus (une URI complète).

Intermède

Faisons une petite pause pour observer ce qu’a réalisé la commande ci-dessus, et peaufiner un peu les choses.
La commande a donc créé un nouveau dossier myproject. Celui-ci est vide à l’exception d’un sous-dossier .git, puisque c’est effectivement un repository Git ordinaire.
Mais alors quid des métadonnées SVN que j’ai mentionnées ? Celles qui nous intéressent sont présentes dans le fichier .git/config :

On y voit l’adresse du serveur, et la configuration des différents types de branches (pour rappel le trunk et les tags SVN sont des branches ordinaires qui suivent juste une certaine convention de nommage).

Le trunk SVN sera donc récupéré dans la branche git ref/remotes/trunk.
Les branches, elles, iront directement en vrac dans ref/remotes/*. Aïe. C’est mal. Pour rappel la convention pour les branches remote d’un repository distant appelé origin sont de la forme refs/remotes/origin/*. Ici, si on ajoute par la suite un autre repository remote, ça va être le gros mélange dans les branches des différents remotes. On va donc arranger un peu ça, et mettre toutes les branches remote du serveur Subversion dans un sous-dossier :

Récupération de l’historique

Maintenant qu’on a bien configuré notre repository local, on va récupérer l’historique de notre serveur Subversion.

Le premier appel à cette commande va récupérer l’ensemble des révisions et des branches du projet. Un serveur Subversion n’étant pas conçu pour ça, il n’y a pas d’autre solution que de récupérer toutes les révisions une par une, en commençant par la toute première, puis en appliquant les révisions les unes à la suite des autres. Pour un gros repository, ça peut être long. Très long. Ça peut aller jusqu’à plusieurs jours pour un repository avec des dizaines de milliers de révisions.

Si on est pressé par le temps, et qu’on n’a pas besoin de tout l’historique des révisions, on peut limiter le nombre de commits récupérés. Pour cela, ajouter le paramètre -r qui précise la première révision à récupérer. Dans ce cas, faire bien attention à préciser une révision antérieure à la création des branches et tags que l’on va effectivement utiliser.
En effet Subversion ne sauvegarde pas le “point de départ” des branches, donc il faut que Git-SVN ait suffisamment de données pour reconstituer ce point dans l’arborescence Git.

On pourrait aussi préciser un filtre sur les branches à récupérer, mais je ne le conseille pas : ce n’est pas tellement plus rapide à initialiser, mais par contre ça sera pénible par la suite pour créer ou suivre de nouvelles branches.

Une chose importante à noter est que, comme les tags Subversion sont en réalité des branches, ils sont récupérés sous la forme de branches Git dans refs/remotes/svn/tags/*.

Manipulations locales

À ce stade, on a un vrai repository Git local, qu’on va pouvoir manipuler localement comme n’importe quel repository Git, avec les commandes habituelles : git status, git log, git add, git rm, git commit, etc. Créez des branches locales autant que vous voulez. Par contre pour rapatrier vos branches locales dans les branches partagées, privilégiez le rebase plutôt que le merge : on verra plus bas que le détail de la branche de feature seront sinon perdues.

Synchronisation avec le repository Subversion distant

Pour récupérer les modifications distantes (équivalent d’un git fetch), on utilise la commande :

Cette commande met à jour les branches remote, mais ne touche pas les branches locales, exactement comme le fait git fetch.

Pour mettre à jour la branche locale courante, on peut lancer la commande suivante :

Cette commande est à peu près équivalente à la commande git pull –rebase. Elle effectue un git svn fetch (pour la branche courante uniquement), suivi d’un git rebase de la branche locale sur la branche remote.
Il n’existe pas d’équivalent du git pull standard, puisque les commits de merge (commits avec plusieurs parents) ne sont de toutes façons pas gérés par Subversion.

Pour envoyer les modifications locales vers le serveur Subversion (équivalent d’un git push), on utilise :

Attention, cette commande est assez particulière. Contrairement à un git push, les commits envoyés sont détruits, puis recréés à partir des données récupérées de Subversion, comme si on avait fait un rebase dessus. Ceci permet de s’assurer que le repository local représente bien l’état du repository Subversion, en ajoutant les données de la révision subversion dans le commentaire, mais aussi et surtout, ça permet de se débarrasser des fonctionnalités de Git non supportées par Subversion, comme par exemple les commits de merge.

Manipulations de branches et de tags

Pour créer une branche Subversion, utiliser :

Pour un tag :

Ces commandes manipulent directement le repository distant. Pas besoin donc d’effectuer un dcommit par la suite.

Pour modifier une branche distante, le fonctionnement est identique à la manipulation d’une branche remote Git : on crée une branche locale à partir de la branche distante, on modifie, on commite et on push/dcommit.

Limitations

On a vu les manipulations qui marchent. Maintenant attardons-nous un peu sur les points auxquels il faudra faire plus attention.

Merges

Comme on a pu le voir, la limitation la plus impactante est due à l’absence de gestion des merges par Subversion, qui occasionne des rebase à tout va.

En l’absence de suivi des merges, le suivi des reports de modifications d’une branche à l’autre est compliqué (un peu comme dans subversion seul, en fait) : difficile après un merge de savoir quelles modifications ont été reportées ou non.
La solution, non optimale, que je préconise pour garder un suivi correct des reports de corrections d’une branche de recette à une branche de développement est l’utilisation de cherry-picks : les commits sont copiés un par un d’une branche à l’autre. Ainsi on n’a certes pas les infos du merge, comme la branche d’origine, mais on peut voir les modifications mieux qu’avec un gros commit qui regroupe toutes les modifications.

Rebases

En règle générale, il faut être bien conscient de quels commits ont déjà été synchronisés avec SVN, et surtout ne jamais les modifier. Avec Git c’est déjà mal. Avec Git-SVN ça tue des chatons. Il y a vraiment moyen de pourrir un repository Subversion avec des rebases mal maîtrisés.

Commits non atomiques

Un autre point d’attention est le fait que la commande git svn dcommit n’est pas atomique. Il faut bien être conscient qu’elle peut en fait effectuer plusieurs envois (svn commit) successifs, intercalés par des fetch et des rebase. Il faut donc éviter d’envoyer ses modifications en même temps qu’un autre utilisateur. Il m’est déjà arrivé de voir deux commits fusionnés localement en un (un local et un distant) dans un cas comme ça.

Branches de tracking

L’information de la branche remote associée à une branche locale n’est pas persistée. La branche SVN à prendre en compte lors d’un git svn rebase ou git svn dcommit est trouvée à l’exécution : c’est la branche remote la plus “proche” du HEAD, la première trouvée en redescendant l’arbre.
On peut ainsi avoir quelques surprises. Par exemple en appelant par erreur un git svn dcommit depuis une branche locale créée depuis le master, on va mettre à jour la branche trunk avec le contenu de la branche locale.
La meilleure façon de ne pas se tromper est d’utiliser les commandes remote uniquement depuis les branches locales créées à partir d’une branche remote. Ainsi pour créer une nouvelle branche subversion, utiliser d’abord git svn branch, puis créer la branche locale à partir de la branche distante nouvellement créée.

Partage de repository

Un gros problème, c’est que le hash d’un commit issu de Git-SVN n’est pas unique. Ainsi si deux développeurs utilisent Git-SVN à partir du même repository Subversion, les commits n’auront pas les mêmes identifiants. On ne pourra donc pas partager simplement une branche de travail entre deux développeurs.

Conclusion

J’espère que vous avez pu voir que cet outil est puissant, mais potentiellement dangereux si mal utilisé. Gardez donc à l’esprit que c’est un outil de transition, pas une solution à long terme. Et migrez vers Git !

D’un projet WTF

Le javascript est à la mode, il est donc utilisé à toutes les sauces. On le trouve côté serveur, on compile du bytecode llvm vers du js, on fait des jeux avec, on peut même l’utiliser pour attaquer les libertés fondamentales des utilisateurs. Dans toutes ces librairies, on trouve par exemple JSZip, une librairie js qui permet de générer des fichiers zip côté client. Sans intervention du serveur (parce que utiliser java.util.zip, c’est tricher), on pourra donc créer le binaire représentant un HelloWorld.txt zippé :

Récupérer ce binaire n’est pas facile, mais on a vu pire.

À une contribution OMGWTFBBQ

L’élément déclencheur est ici une feature request dans le bug tracker sur github :

It would be great to have a two-way zipfile object that can be created from a file, modified and downloaded as a file.

Avec des motivations telles que :

• for the lulz
• because I can

Il m’était impossible de ne pas tenter l’écriture d’un parser zip en js.

Les principales difficultés furent :

• un fichier zip se lit à l’envers. Commencer par le début pose trop de problèmes (mais je l’ai su après).
• IE. Charger un fichier binaire en ajax demande du code vbscript. DU CODE VBSCRIPT.
• mes idées du type “tiens, et si j’ajoutais la gestion du ZIP64, prévu pour les fichiers de plus de 4Go ?”

Au final, ça donne une pull request conséquente (+7472, -1092) qui ajoute la possibilité de lire des zip dans un navigateur. Même des jar (avec leurs data descriptor), même des stream zippés (avec leur extension ZIP64), même des zip avec des symboles UTF8 bizarres dans le nom des fichiers, même dans IE6.

Ça donne également un sacré sentiment d’accomplissement quand la pull request est acceptée

Article écrit sous Creative Commons 3.0 BY-SA.

Précautions à prendre au cours de l’utilisation de rebase

• Evitez d’utiliser cette commande sur des révisions qui ont déjà été poussées sur le dépôt distant.
• En cas d’erreur, n’oubliez pas que vous avez toujours la possibilité de revenir sur vos pas grâce aux commandes git reflog et git reset.

Comment masquer les révisions de merge

A la révision C, je me dis que mon travail (mes_devs) peut être poussé sur la branche [origin/master] (la branche de référence du dépôt distant).
A ce moment là, si je choisis de merger ma branche avant de pousser mes modifications, Git génère une révision de merge H :

La révision H ne sert pas à grand chose et au final mes collaborateurs voient une boucle dans l’historique du projet.
Personnellement, je pense que créer une branche locale pour chaque nouveau développement est une bonne pratique mais pas au point de la voir apparaître dans l’historique distant sous forme de boucle.
Multipliez cette boucle par le nombre de collaborateurs et votre gitk finit rapidement par vous afficher un historique qui ressemble à ceci.

Revenons un peu en arrière :

En utilisant la commande git rebase, il est possible d’appliquer les modifications des révisions A, B et C sur la révision G:

On peut alors merger notre branche master pour maintenir notre historique linéaire.

Mon historique s’en trouve nettement simplifié et la santé mentale de mes collaborateurs est préservée.

Utilisation de rebase dans la commande pull

Si je lance la commande git pull sans la moindre option, j’obtiens ceci :

Si je lance la commande git pull –rebase, je change le comportement par défaut de la commande git pull pour qu’elle devienne l’équivalent de git fetch + git rebase pour m’épargner la création du commit de merge:

Comment modifier ses révisions avant de les pousser

Avant d’appliquer la procédure décrite dans la section précédente, je me rends compte que mes révisions ont été mal définies. Les révisions A et B correspondent à la correction d’un même bug si bien que la révision A n’a aucune raison d’exister seule.
De plus, la révision C contient une évolution et une correction de bug complètement décorrelées.
Si vous tenez à pousser des révisions qui ont du sens, alors l’option -i (ou –interactive)de git rebase est ce que vous cherchez.
La commande suivante va nous permettre de travailler sur l’historique de la branche courante en se limitant aux 3 dernières révisions:

Le mode interactif de git s’active et vous verrez alors les lignes suivantes dans un éditeur de texte:

C’est là que vous pouvez agir sur votre historique en remplaçant le mot clé “pick” par une des commandes suggérées par le mode interactif de git.
Vous pouvez supprimer ou changer l’ordre des commits en supprimant/échangeant les lignes correspondantes. Il ne faut surtout pas chercher à modifier les clés (hash) identifiant les révisions.
Dans notre exemple nous voulons appliquer les opérations suivantes :

• Changer le message de A.
• Combiner A et B sans conserver le message de B.
• Séparer la révision C en C1 et C2.

Ce qui nous donne :

Git va vous inviter à saisir le message de commit de la révision A dans un premier temps.
Ensuite, vous devrez restaurer le système de fichiers à l’état qui précédait le commit de la révision C avant de reconstruire les révisions C1 et C2.

Vous finissez avec l’arborescence suivante :

Cette table, qu’on appellera USERLINK permet d’associer un object User soit avec une Company soit avec un BankAccount. Dans la table, on a une colonne LINKTYPE qui permet justement de savoir de quel type est l’association.

Jusque là tout va bien, on choisit la stratégie Hibernate “Table per class hierarchy” et on utilise la colonne LINKTYPE comme discriminant. On obtient alors un fichier de mapping de ce genre :

De l’autre coté, dans le mapping de la classe User on rajoute les sets qui vont bien :

Tout ça ne semble pas trop mal, Hibernate a maintenant toutes les informations dont il a besoin, et pourtant…
Lorsqu’on essaye de récupérer tous les liens d’un utilisateur vers ses sociétés :

on récupère un Set qui contient plus d’objets que prévu.

Pour comprendre ce qui se passe on active les logs Hibernate et on se rend compte que ce dernier omet tout simplement d’utiliser le discriminant (pas de “WHERE LINKTYPE=?” dans les requêtes).
Un petit tour dans la doc Hibernate et on trouve notre parade :

En effet dans ce cas particulier, “mapping d’une association dont le type est mappé avec un discriminant”, il est nécessaire de forcer l’utilisation de ce dernier avec le paramètre force=”true”.

Bug Hibernate ou mauvaise modélisation, dans tous les cas il n’est pas naturel de devoir forcer l’utilisation du discriminant. Certains se sont déjà posés la question mais je n’ai pas un avis tranché à ce jour. Et vous, qu’en pensez vous ?

Le projet est composé de 3 parties :

• The Commons Proper : Principale partie, elle contient l’ensemble des utilitaires Java.
• The Commons Sandbox : Repository SVN qui fonctionne comme un workspace pour la collaboration sur les projets en cours, destinés à faire partie des Commons Proper.
• The Commons Dormant : Projets de Sandbox qui sont inactifs.

Commons Proper est composé de nombreux modules qui regroupent des utilitaires par sujets. On trouve par exemple : Commons Collections, Commons Lang, Commons Logging,  Commons Pool, …

Pour quoi faire ?

Le travail de développeur consiste non seulement à écrire du code, mais également et surtout à réutiliser ce qui existe déjà.
En plus d’être généralement moins couteux en temps et en énergie, la réutilisation réduit le travail redondant et permet d’utiliser du code qui a été pensé et écrit de manière optimale. C’est donc un gain de temps et de performance (à condition de ne pas prendre n’importe quel code …).
Les Apache Commons sont créés avec cette optique. Ils proposent de très nombreux utilitaires pour répondre aux petits problèmes auxquels sont régulièrement confrontés les développeurs. Ils sont simples et rapides à mettre en place et à comprendre et existent pour des sujets divers et variés.

Que ce soit pour travailler sur des Strings ou des Collections, en ligne de commande, pour communiquer avec une base de données, lire des fichiers de configuration, logger, travailler avec des fichiers XML, créer des emails, uploader du contenu, faire des statistiques, … (la liste est longue !) il y a les Apache Commons pour nous simplifier la vie !

Exemples :

Etablir une liste exhaustive de ce que proposent les Apache Commons prendrait beaucoup de temps.
Je vais donc présenter par des exemples quelques une des librairies existantes.

Commons Lang :

Additions au package java.lang : chaines de caractères, calculs, réflexion, sérialization, etc.

ToStringBuilder :

Ce qui affiche : “ExampleToStringBuilder[name=bonjour,counter=123,isOk=true]”

Il existe le même genre d’outils utilisant la réflexion avec EqualsBuilder ou encore HashCodeBuilder :

Commons Configuration :

Cette librairie propose une manière générique de charger sa configuration en provenance de sources très diverses. Elle permet également un accès typé aux paramètres :

La configuration peut être chargée en provenance de multiples sources :

• Properties files
• XML documents
• Windows INI files
• Property list files (plist)
• JNDI
• JDBC Datasource
• System properties
• Applet parameters
• Servlet parameters

Commons Collections :

Cette librairie est construite comme une couche supplémentaire sur les Collections du JDK. Elle propose des utilitaires pour travailler avec les collections, mais également de nouvelles interfaces et implémentations.

Parmi les utilitaires, on trouve une classe par interface de Collection du SDK (MapUtils, ListUtils, …).

Pour ce qui est des interfaces, on a notamment Predicate qui est utilisée pour évaluer un objet, c’est-à-dire vérifier qu’il remplit bien certaines conditions, ou encore Transformer, qui permet de transformer un objet en un autre selon des critères définis dans les implémentations.

Il y a aussi de nouvelles Collections comme le Bag qui représente une collection d’objet avec un certain nombre de copies pour chaque élément :

Une nouvelle hiérarchie totale de Collection est proposée pour les map bidirectionnelles : BidiMap.

Et ce n’est encore une fois que de simples exemples parmi tant d’autres possibles !

Conclusion

Les Apaches Commons peuvent être utiles quotidiennement. Il est bon de savoir que ces librairies existent, et d’aller voir régulièrement s’il n’y a pas une méthode correspondant à ce que l’on cherche avant de l’écrire soit même !
Les sources sont également très intéressantes pour regarder comment de simples choses peuvent être faites de manière performante.

Je n’ai donné ici qu’un très bref aperçu de l’étendue de ces librairies, à vous d’aller en voir plus !

La manipulation d’arguments d’une application peut devenir vite contraignante quand il s’agit de les traiter comme des options.

En raison de sa simplicité et de sa taille (das le but de créer un uberJar), j’ai opté pour l’utilisation d’Args4j et ce, malgré la présence d’autres projets, tel que Commons CLI.

Je vais vous faire découvrir cette librairie à travers une explication détaillée. Vous trouverez les sources citées dans cet article sur mon github.

Pour commencer, on va créer une classe qui va nous permettre de déclarer toutes les options de notre application :

On va procéder à la déclaration de la première option dans notre application qui aura pour intérêt de définir obligatoirement un nom en tant qu’option.

La première chose que l’on puisse remarquer est l’utilisation d’annotation. Cela participe grandement à la lisibilité et la clarté de notre code mais cependant nécessite d’avoir au minimum un JRE en version 1.5.
Ainsi, nous avons déclaré notre attribut de type String de manière classique, qu’on a ensuite précéder de l’annotation @Option avec différents paramètres.
Voici une description de chacun de ces paramètres :

• name : représente le nom de l’option
• usage : permet de définir une description de l’option
• metaVar : modifie le type affiché lors de l’affichage de l’utilisation de l’option
• aliases : crée un alias au paramètre name, souvent utilisé pour définir des options avec un nom plus complet
• required : comme son nom l’indique, permet d’indiquer si cette option est obligatoire (false par défaut)

Si l’option n’est pas obligatoire, il est possible de lui définir une valeur par défaut. Ceci en initialisant tout simplement notre attribut :

Si nous devons également définir une liste ou autre collection, il suffit d’utiliser le paramètre multiValued sur notre annotation.

Voilà, nous avons vu quasiment tous les types de paramètre possible sur nos options. Un dernier point qui peut s’avérer très utile, Args4j va nous permettre de récupérer tous les arguments de notre programme dans une liste, grâce à l’annotation @Argument :

Si nous voulions définir un nombre précis d’argument avec un ordre spécifique, il suffirait d’annoter chacun de nos attributs avec @Argument et de mettre le paramètre index :

( L’index commence bien-sur à 0 )

Jusqu’ici, nous avons utilisé que des types de base, mais comment faire pour définir une option (ou argument) d’un type complexe ?

On crée tout d’abord une classe Complex.java, qui va représenter un nombre complexe dans notre cas.

Ensuite on déclare un attribut de type Complex et ajoutons parmi les paramètres de l’annotation un handler.

Ce handler va permettre de gérer la création de notre attribut à l’aide de la valeur passée à l’option. Pour cela, le handler doit hériter de la classe OptionHandler et ainsi implémenter les différentes méthodes nécessaires. La première est getDefaultMetaVariable() qui va permettre de définir, comme vu auparavant, le paramètre metaVar de notre option. Si le paramètre metaVar est défini sur l’annotation, alors sa valeur écrase la valeur du handler. La seconde méthode est parseArguments(String[]). Cette méthode va permettre de récupérer la valeur de l’option fournie en ligne de commande pour que l’on puisse effectuer le traitement dans cette méthode et créer notre attribut complexe.

Pour finir, on n’oublie pas les getters/setters. Apres quoi, nous pouvons passer au point d’entrée de l’application.

Nous déclarons et instancions notre bean contenant toutes nos définitions d’options et arguments que l’on passe à un CmdLineParser. Ce parser va s’occuper de faire tout notre travail, il suffit d’appeler parseArgument(args). Si une option n’existe pas ou est mal formée, alors une exception sera levée et l’on affiche à l’utilisateur le manuel d’utilisation de l’application. Voici un exemple de ligne de commande correcte :

On remarque que pour utiliser l’option du type boolean il suffit juste de spécifier l’option suivi d’aucune valeur. Si on regarde dans le pom, on voit qu’on utilise actuellement la version 2.0.16 de Args4j, qui est la dernière version disponible sur le repository de Maven.

Depuis la version 2.0.19, Args4j permet de spécifier la valeur de notre option pour le type boolean. Avant la version 2.0.19, si une valeur était spécifiée pour une option de type boolean, alors cette valeur était prise comme argument de l’application. Pour ceux qui voudraient utiliser la version 2.0.19, vous devez rajouter le repository de Glassfish à votre pom.

Enfin, lorsqu’on essaye de lancer cette application sans aucun argument (ou que nous faisons une erreur de saisie), on se retrouve avec un joli message d’explication ainsi que les différentes options possibles et un exemple d’utilisation :

Voilà à peu près tout pour cette librairie assez sympa !

Vous trouverez les sources de cet article sur mon repository github.

« Pourquoi ne pas faire découvrir à ceux n’ayant pas eu la chance d’assister à cette conférence ce qu’est cet outil ?».

Je tiens à souligner que cet article est avant tout un article « découverte », je ne rentrerai donc pas aujourd’hui dans les détails. Cependant, je pense creuser un peu plus durant les mois à venir. Je posterai donc très probablement d’autres articles sur cet outil.

Mais alors, qu’est-ce que c’est ?

SpringFuse est un générateur de code Java 1.6 (1.7 dans les prochaines releases). Il permet, entre autre, de générer du code Java représentant votre modèle de données ainsi que vos DAO (Data Access Object) et vos services. Il peut aussi générer des tests unitaires.

Mais sur quoi se base-t-il ?

SpringFuse s’appuie sur la base de données de votre application. Pour générer au mieux le code de votre application, il va utiliser plusieurs technologies du marché actuel ainsi que sur Celerio développé par l’éditeur Jaxio. Parmi les différentes technologies utilisées, voici une liste non exhaustive des plus connues.

• Spring, framework pour la construction d’applications Java,
• JPA 2, utilisé pour tout ce qui est persistance,
• Spring Security, qui est un module de Spring pour la gestion de la sécurité,
• Maven 2, pour la gestion de votre projet Java.

Il est pour le moment possible de générer 3 types de projets :

• On peut générer un projet utilisant Spring Web Flow (utilisé pour la gestion de flux, notamment pour tout ce qui est formulaire) et JSF pour la vue,
• On peut également générer un projet utilisant Spring MVC et JSP,
• Enfin, si vous voulez utiliser une autre technologie pour gérer la vue, il est possible de générer seulement le back-end de votre projet.

Pourquoi l’utiliser ?

Pour le moment, je n’ai utilisé aucun autre générateur de code. Par conséquent, il est pour moi encore très difficile de conseiller celui-ci plutôt qu’un autre. Cependant, voici quelques points me paraissant intéressant :

• Le code produit est relativement propre et compréhensible,
• Les développeurs de SpringFuse s’efforcent d’utiliser les meilleures technologies du moment,
• Il est grandement configurable,
• Il est facile à utiliser,
• Il a un taux de mise à jour important, apportant sans cesse de nouvelles améliorations (changel-log.html).

On peut utiliser cet outil pour une application bancaire par exemple. Via l’intégration de Spring Security, le développeur a la base de la sécurité de l’application, il faut bien entendu ensuite renforcer celle-ci mais les fondations sont là. De plus, les tests unitaires de l’application sont déjà fournis. Par conséquent, le développeur peut plus facilement gérer la non régression de celle ci.

Il peut être aussi utilisé pour faire des prototypes. En effet, ici, le développement de la partie « basique », c’est à dire ce que génère SpringFuse, n’est pas la première préoccupation des développeurs. On peut donc partiellement exclure cette partie que l’on peut qualifier de répétitive grâce à ce générateur.

Enfin, un dernier petit exemple. Si vous êtes tous simplement débutant dans les technologies JEE, vous pouvez utiliser ce générateur afin d’avoir des exemples concrets par rapport à votre projet personnel plutôt qu’un exemple sur le net qui peut être insuffisant.

Ajoutons à cela la problématique de l’entreprise : Le temps. On vit dans un monde où le temps est important, et ici l’expression « le temps, c’est de l’argent » prend tout son sens.
Cela peut par exemple être une aide au développement pour la migration d’anciennes applications. Ce genre de projet est souvent coûteux pour l’entreprise et cela explique (dans certains cas) que certains projets n’ont pas été migrés depuis 10, 20 ou 30 ans car trop complexe et/ou trop coûteux. Avec ce genre d’outil, le coût de développement peut être beaucoup moins important même si cet outil ne suffit certainement pas pour certaines applications très complexes. Cependant, vous aurez au final la “tuyauterie” de votre application, une base solide. A vous ensuite de personnaliser le code pour peaufiner les règles métiers, en ajouter d’autres, etc. et tester votre code via les tests unitaires fournis. SpringFuse intègrera bientôt Sélénium 2 permettant d’effectuer des tests fonctionnels pour votre application.

Seul petit bémol, le serveur ne génère qu’une seule application n’utilisant pas le mode multi-projet de Maven. C’est à vous de découper.

Je suis intéressé, de quoi ai-je besoin ?

Pour pouvoir utiliser au mieux SpringFuse, il est impératif d’avoir trois choses :

• Un ordinateur ,
• Java 1.6,
• Maven 2.

Et c’est tout ! (enfin je vous conseille Eclipse pour visualiser le code généré)

Le fonctionnement

Pour pouvoir générer un projet, il faut passer avant tout par une phase de configuration. Il existe une phase de configuration simple et une phase de configuration avancée. Je ne vous parlerai que de la phase simple et reviendrai dans un autre article sur la configuration avancée passant par différent fichiers XML.

Via un formulaire où l’on va renseigner diverses informations dont :

• Le nom de notre projet,
• Le moyen d’accès à notre base de données,
• Le type de projet que l’on va générer
  

  Formulaire pour la génération du code disponible sur http://www.springfuse.com/

Après renseignement de tout ceci, une commande Maven est proposée afin de générer et télécharger le nouveau projet.

On peut remarquer que les informations insérées dans le formulaire sont présentes dans la commande et seront envoyées au serveur.
Lorsque celle-ci est exécutée dans votre terminal préféré, le serveur de SpringFuse va recevoir les informations (les métadonnées) de votre base de données et va générer le code correspondant au mieux à votre schéma de données par introspection (il existe également un mode démo pour ceux qui seraient seulement curieux et qui ne voudraient pas envoyer les métadonnées de leurs bases). Le code est généré côté serveur, cela peut prendre plusieurs minutes car le serveur :

• Analyse les métadonnées de la base que vous lui avez envoyée. Plus la base est complexe et plus cela prend du temps,
• Génère le code de votre application,
• Génère également les tests unitaires et les exécute ensuite afin de vous envoyer un code correct.

Une fois cette phase finie, le code généré est téléchargé et sauvegardé sur votre machine.

Processus de génération du code d’un projet

Il est alors possible de travailler à partir du code généré. Il est très facile de l’importer dans Eclipse en utilisant l’option « importer un projet Maven déjà existant » avec le plugin M2eclipse de sonatype. Je vous laisse le soin de faire un test via la démo pour vous faire votre propre idée.

Le mot de la fin

Je pense que SpringFuse n’est certainement pas la réponse à tous les problèmes d’intégration et de traitement de données mais la génération de code peut apporter une grande aide. Le code étant généré de façon à ce que votre application puisse directement se lancer.
Les outils en la matière sont nombreux, il en existe certains transformant du code d’un langage en un autre, d’autres comme celui que je viens de présenter. Leurs applications sont nombreuses et permettent souvent de gagner du temps.
Il existe des générateurs de code dans beaucoup d’autres langages (Java, .Net, PHP, …), le but étant toujours de faciliter le développement de nouvelles applications.
Voilà pour cette petite présentation de SpringFuse. Je vais tenter d’approfondir l’utilisation de cet outil et essayerai de faire d’autres articles dans les prochains mois.

Le binding est une des facilités de Grails : disons qu’on ait un objet User, contenant les propriétés lastName, firstName et birthdayDate. Notre formulaire de création/édition d’utilisateurs aura les champs correspondants. Dans le controlleur, on peut remplir notre objet User en écrivant simplement :

Mais pour binder la date birthdayDate, la map params doit avoir les champs birthdayDate, birthdayDate_year, birthdayDate_month, birthdayDate_day, birthdayDate_hour et enfin birthdayDate_minute. Ces champs sont automatiquement générés par la balise <g:datePicker /> fournie par Grails, mais dès qu’on n’utilise plus cette balise (date picker personnalisé, utilisation d’un input text classique…), il faut générer soi-même tous les champs. C’est beaucoup trop long, lourd et complétement inadapté.

Heureusement, on peut également indiquer à Grails d’autres façons de binder des objets en créant un PropertyEditorRegistrar. Cet objet “enregistre” différents types de conversion textobjet. Pour chaque type de conversion, on crée une classe étendant PropertyEditorSupport.
Concernant les dates, la classe CustomDateEditor est déjà présente dans le package de Spring, mais n’est pas “enregistrée” par défaut. Dans notre cas, il nous suffit donc d’enregistrer un CustomDateEditor.

Rien de bien compliqué ! Ce “convertisseur” gère même l’i18n (il faut donc ajouter une propriété dateFormat.day dans les fichiers messages.properties pour que le code ci-dessus fonctionne)

Il ne reste plus qu’à déclarer ce “registrar” en tant que bean, dans le fichier Configuration/spring/resources.groovy :

Encore peu répandu en France, certains d’entre vous en ont peut-être déjà entendu parlé sur des blogs informatiques ou par le biais d’une offre d’emploi. Pour les autres, je vais essayer de répondre de la manière la plus concise possible à cette question qui vous brûle les lèvres :

Mais c’est quoi le DevOps ?
Le DevOps est la contraction des deux mots Anglais « Development » et « Operations », ou traduit respectivement en Fraçais « Développement » et « Exploitation ».

Il s’agit d’un mouvement dont le but est de définir un ensemble de règles et de techniques permettant aux différentes équipes (développement, tests et exploitation) de communiquer efficacement, ainsi que travailler à la fois en coopération et de manière optimale, le tout afin d’améliorer la qualité du produit.

Ce petit schéma situe la place du DevOps parmi les autres entités d’un projet :

Le DevOps situé à l'intersection entre de développoment, l'exploitation et la qualité (issu de Wikipédia)

Qu’est-ce que cela apporte, concrétement ?
Dans les grands projets informatiques, il existe généralement différentes équipes dont les rôles sont bien définis.

Principalement, il s’agit de l’équipe de développement, d’un côté, et celle chargée de l’exploitation de l’autre.
En temps normal, les équipes de développement tentent de répondre à des spécifications fonctionnelles en provenance du métier ou du client. Elles travaillent dans leur propre environnement avec leurs outils optimisés pour les développements et ne se soucient pas de l’impact que peut avoir leurs codes lors de la phase d’exploitation qui, généralement, exécute l’application sur un environnement différent.
Les équipes placées du côté de l’exploitation tentent de répondre à des requis non fonctionnels tels que les performances ou la stabilité du système. De ce fait, elles sont plus enclin à minimiser l’impact des modifications afin de conserver ces performances, et cela peut constituer un goulot d’étranglement pour l’ajout de nouvelles fonctionnalités aux applications.
Mais qu’on soit dans une équipe ou dans l’autre, il est malheureusement très fréquent que chaque équipe ne soit pas consciente de comment l’autre équipe gère sa tâche (c’est-à-dire comment les développeurs codent et comment est configuré l’environnement d’exploitation), rendant difficile l’optimisation des deux côtés.

C’est là qu’entre en jeu le DevOps qui se chargent en quelque sorte de faire le pont entre les différentes équipes afin de faciliter la communication et de propager l’information utile. Ses autres fonctions incluent aussi l’amélioration de la coordination lors des phases de livraisons et de déploiements (cela est surtout important pour des projets demandant des déploiements réguliers, comme plusieurs fois par jour), ainsi que la mise en place d’automatisation des déploiements afin de limiter les erreurs.

Le DevOps, c’est un métier ou pas finalement ?
Pas exactement, il n’existe, à ce jour, pas de métier dédié entièrement au DevOps. Il faut plutôt voir cela comme une voie de spécialisation dans laquelle on peut vouloir s’engager. Néanmoins, un ingénieur DevOps doit être polyvalent et être capable de comprendre facilement les contraintes associées à la fois au développement et à l’exploitation. Son domaine de connaissance doit être assez vaste, même si sa principale fonction est le développement JEE, par exemple…
Si vous êtes intéressés par cette fonction, il existe de nombreuse offre d’emploi en ce moment (plutôt aux Etats-Unis) qui recherchent des DevOps Software Engineer. Leur lecture vous apportera sûrement des réponses à vos interrogations.

Sinon, pour encore plus de détails, je vous invite tous à assister au Paris JUG du mois de Janvier 2012 qui sera une soirée DevOps.