Compiler les sources de HtmlUnit

Il est toujours intéressant d’essayer de recompiler les projets libres, surtout lorsqu’il s’agit de projet de taille moyenne. HtmlUnit est un projet libre écrit en java, le langage de programmation que j’utilise habituellement. En plus, il s’agit d’un outil que j’utilise actuellement dans le développement d’une application web. Enfin le projet semble de qualité avec plusieurs développeurs différents, des métriques de code, des conventions d’écriture de code et des tests unitaires.

Pour rappel, htmlUnit est « un navigateurs web pour programme Java ». Sur le site officiel, on peut lire la phrase suivante « HtmlUnit is a browser for Java programs ». Il s’agit d’une API qui simule un navigateur Web. Associé avec JUnit, HtmlUnit permet de faire des tests unitaires des applications web côté présentation. Ici, j’utilise la dernière version (1.13) du projet.

Le projet utilise Maven, mais dans l’exemple suivant je vais utiliser Ant. Ant permet d’automatiser les taches pour les projets Java. Il faut utiliser la dernière version de ant (1.7.0) pour ce projet. Maven va beaucoup plus loin en gérant les dépendances. Une fois que le projet est téléchargé, décompressé, on repère facilement qu’il y a un fichier build.xml, le fichier nécessaire à ant pour savoir les différentes tâches à effectuer. Dans le répertoire où se trouve ce fichier, il suffit de passer la commande « ant », et espérer avoir le résultat « build successful » et surtout d’obtenir un nouveau fichier jar « htmlunit.jar ». Mais la première fois vous aurez sans doute le résultat « build failed » et de nombreuses erreurs.

Le problème est qu’il manque les jars nécessaires à la compilation du projet. Le site du projet détaille les dépendances. Il est donc possible de rechercher et télécharger les jars nécessaires à la compilation. Cependant, ce n’est pas utile car tout est déjà dans le fichier de configuration de ant (build.xml). Dans celui-ci, les taches sont définis par les balises « target ». Il existe des dépendances entre tâches avec l’attribut depends, c’est à dire les tâches à effectuer avant de faire la tâche, par exemple avant de créer le jar, il faut effectuer la compilation. Il existe une tâche « get-jars » qui va télécharger les jars nécessaires aux autres tâches. Donc il suffit de passer la commande « ant get-jars ». Bien sûr une connexion à Internet est nécessaire. Il faut faire également attention au éventuel blocage du aux firewall. Vous pouvez vérifier le bon déroulement de cette étape avec la création du répertoire ant-jars, et la création de deux sous-répertoires contenant les jars pour le projet et les jars pour les tests unitaires.

Maintenant, nous allons tenter de compiler les sources et d’effectuer la commande « ant-compile ». Cette étape compile les sources du projet et les sources des tests unitaires. Vous pouvez vérifier le bon déroulement de cette étape en vérifiant la création d’un répertoire ant-target et par le fait qu’il contienne les fichiers compilés des sources et des tests.
Maintenant, passons à l’étape checkstyle. il s’agit d’un outil de contrôle de code. Il vérifie le bon respect des conventions de code. Le sujet des conventions de code est un sujet assez vaste notons que Sun a publié ses règles de bonne écriture du code Java. Donc utilisons checkstyle avec la commande « ant checkstyle ». Si vous êtes sous Windows vous serez noyés par les messages « il manque un caractère NewLine à la fin du fichier ». Ceci vient que les développeurs utilisent des fichiers de type Unix. Il faut corriger le fichier checkstyle.xml et préciser que les fichiers utilisent la convention de fin de ligne Unix.

La règle :

<module name="NewlineAtEndOfFile/">

devient :

<module name="NewlineAtEndOfFile">
	<property name="lineSeparator" value="lf"/>
</module>

Maintenant, cette étape doit se passer sans problème.

L’étape suivante est d’effectuer les tests unitaires. La commande est ant junit. Sur mon poste, 12 tests ne passent pas. Je n’ai pas cherché à voir d’où venait ce problème. Simplement, notons que ce projet utilise gsbase (http://gsbase.sourceforge.net/) une librairie qui complète JUnit. Par exemple, il existe la classe « orderedTestSuite » qui assure que les tests soient effectués dans un ordre déterminé. Dans ce cas sont-ils encore unitaires ?

Enfin, la dernière étape est de créer le jar. Il suffit de passe la commande « ant jar » ou « ant » seule. J’ai modifié un peu l’attribut depends de la tache jar du fait que le test junit échoue et qu’apparemment checkstyle a besoin du résultat de la compilation pour analyser les sources de la partie des tests.

Donc, il y avait :

depends="clean,checkstyle,compile,junit"

J’ai mis à la place :

depends="clean,compile,checkstyle"

Maintenant, le jar est créé. Il est possible d’utiliser et de commencer à faire quelques modifications simples, comme par exemple ajouter des constantes supplémentaires. Autre point , il est toujours possible d’ouvrir le projet sous Eclipse. Ce dernier découvre facilement la configuration ant et peut configurer en partie le projet.

Un tout dernier point, bravo aux membres de ce projet pour la qualité de ce projet.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s


%d blogueurs aiment cette page :