Editeur (IDE) pour le langage Java

février 15, 2009 by petitteckel

Les deux principaux éditeurs (IDE) pour le langage Java sont actuellement NetBeans et Eclipse. Sur le site developpez.com, on trouve des sondages concernant l’utilisation des IDE Java. Les chiffres de ces dernières années montre qu’Eclipse domine largement de 55 à 60%. Le second est NetBeans avec une utilisation qui a tendance à croître au fil du temps. Cette année NetBeans représenterait 36%. En dehors de ces deux IDE, il n’y plus vraiment d’alternative.

Dans le cadre de mon travail, j’utilise une version « ancienne » d’Eclipse. La principale contrainte vient de l’existence de plugins « maison » que très peu de personnes sont capables de maintenir. Cela ne m’empêche pas d’utiliser personnellement Eclipse 4 et de m’intéresser de près des évolutions de NetBeans. La version de NetBeans actuelle est la 6.5 datant du 19/11/2008. Une version 7.0 est en cours de développement.

Voici, quelques plus de NetBeans. Premièrement, la facilité de création de projet de type « Struts » version 1. Ensuite, il existe un module UML disponible pour NetBeans. Dans la version précédente de NetBeans 6.0, ce module était intégré dans la version de base. Il faut maintenant le télécharger si on le désire. Il faut aller dans le menu Tools\plugins pour ajouter les plugins désirés. On peut également rapidement le plugin pour le framework Wicket. Mais il manque forcement toujours quelque chose, par exemple je n’ai pas trouvé de plugin récent pour tapestry.

Quelques journaux ou revues gratuites pour s’exercer aux langues étrangères à Bruxelles

février 15, 2009 by petitteckel

Un petit aller retour en la France et Bruxelles m’a permis de trouver quelques revues et journaux gratuits permettant de lire dans quelques langues étrangères.

D’abord le journal « Flanders Today » est facilement disponible à Bruxelles. Il s’agit d’un journal hebdomadaire en anglais soutenu par le gouvernement flamand. Il est possible de le recevoir gratuitement chez soi pendant un an même hors de la Belgique.

Ensuite Brussel Deze Week ou BDW est un journal en néerlandais. Ce journal concerne l’actualité de Bruxelles. Il est également facilement disponible à Bruxelles. L’abonnement est gratuit uniquement pour les Bruxellois. Le coût reste cependant modeste pour les autres belges (15 euros par an).

Enfin, je ai trouvé le dernier dans le train. En effet, Thalyscope est un bimenstriel (tous les deux mois) en français, néerlandais, allemand et anglais. La dernière langue peut agacer un peu, depuis quand Thalys désert Londres ? Mais je ne connais pas de revue aussi polyglotte.

Personnalisation du rapport Maven2 d’un projet

janvier 12, 2009 by petitteckel

La commande « mvn site » permet de générer l’ensemble des rapports dans le répertoire target\site du projet. La page d’accueil est target\site\index.html. Rappelons que le contenu du répertoire target est généré par Maven. L’équipe de développement ne doit rien y placer manuellement. Son répertoire de travail est src. Enfin la commande mvn clean détruit le dossier target et son contenu. Cette commande reste utile lorsque Maven commence à avoir quelques problèmes.

Il est possible de configurer l’apparence du site. Je l’admet ce n’est pas fondamentalement important pour un petit projet, ou un petite structure. En plus, cela ajoute des fichiers de configuration. Un principe important de Maven est « convention over configuration ». Suivant ce principe, si une configuration n’est pas préciser,Maven utilise la convention par défaut. Ceci permet de réduire au maximum les fichiers de configuration au maximum. Notons qu’il s’agit un mouvement profond dans les outils de développement (comme Ruby on Rails)

Maintenant une grande organisation désire suivre une convention de présentation. C’est possible, il suffit d’ajouter un fichier site.xml dans le répertoire src/site. Il est possible que le dossier « site » n’existe pas encore. Ceci montre encore la puissance de Maven. Voici un exemple de fichier site.xml.


<project>
   <body>
      <links>
         <item name="Apache" href="http://www.apache.org/" />
         <item name="Maven 2" href="http://maven.apache.org/"/>
      </links>
      <menu ref="reports" />
   </body>
   <skin>
      <groupId>org.apache.maven.skins</groupId>
      <artifactId>maven-stylus-skin</artifactId>
      <version>1.0.1</version>
   </skin>
</project>

La partie link permet de créer des liens vers les sites sur l’entête des pages (en général en haut à droite). Le menu reports crée le menu concernant les différentes métriques et rapports (javadocs, rapport de test, couverture de code) définis dans le noeud reporting du fichier pom.xml. La partie skin du fichier site.xml permet de personnaliser l’apparence. Il existe sur les dépôts Maven 4 skin :
maven-classic-skin (version 1.0), maven-default-skin (version 1.0), maven-stylus-skin (versions 1.0 et 1.0.1) et maven-application-skin (version 1.0-SNAPSHOT).

Voici des impressions écran du même rapport avec ces 4 skins.

report-application-skin

report-classic-skin

report-default-skin

report-stylus-skin

Utilisation de Maven2 en tant qu’outils de génération de rapports

janvier 1, 2009 by petitteckel

Maven2 est un outils fascinant pour les personnes travaillant sur les projets Java. Il permet de gérer en premier les dépendances du projet. Mais il fournit d’autres fonctionnalités comme la génération de rapports (recherche de bugs, suivi de conventions de code, métriques), ceci en ajoutant quelques lignes de déclaration. En fait il prépare l’industrialisation des développements.

Les rapports sont générés suivant le cycle normal de Maven, par la commande : « mvn site:site ». Pour la génération de ces rapports, je conseille fortement d’utiliser Maven en ligne de commande et non le plugin m2 d’Eclipse (pour les utilisateurs de cet IDE). En effet, il existe trop de petits bugs dans ces plugins Maven pour Eclipse. Le rapport par défaut prévoit plusieurs informations de bon sens (about, project license, project team) qu’il est possible de renseigner dans le fichier pom.xml du projet.

Il est possible d’ajouter des plugins pour obtenir des rapport supplémentaires. Ceci se fait dans le noeud « reporting » du fichier pom.xml. Le plugin proviennent essentiellement du projet maven lui-même ou du projet mojo.codehaus.org. La déclaration est très simple en général, il suffit d’indiquer le groupId et l’artifactId du plugin. Les maniaques peuvent ajouter le numéro de version. Cette simplicité contraste avec le travail fait avec Ant.

Les premiers plugins que je propose d’utiliser sont en fait des plugins simples qui ne correspondent pas vraiment à des rapports classiques mais à des outils plus généraux. Le premier jxr (ou Xref) met simplement sous forme HTML le code source et celui des tests unitaires. Ce code source sera utilisé par d’autres plugins pour indiquer explicitement les lignes de code en problème. Ainsi, si un plugin (comme checkstyle) dit que telle ligne de code de telle classe ne respecte pas une convention de code, il est toujours plus agréable d’avoir un lien sur la ligne en question. La déclaration de ce plugin dans la partie reporting est :


<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-jxr-plugin</artifactId>
   <version>2.1</version>
</plugin>

Le second plugin est celui qui génère la javaDocs. Il est vrai que le format de la javaDocs est un peu vieillot mais il est largement utilisé dans les projets Java. Ensuite Eclipse permet de générer cette javaDocs, mais l’avantage de l’automatisation et l’intégration dans les rapports.


<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-javadoc-plugin</artifactId>
   <version>2.5</version>
</plugin>

Le troisième est également un plugin « simple ». Il s’agit de Surefire qui génère un rapport des tests unitaires dans le cadre des frameworks JUnit ou TestNG. L’écriture des tests unitaires est un point important pour un développement de qualité. Il faut cependant admettre qu’avoir le bon niveau de test n’est pas évident. Un détail important Maven ne semble pas exécuter les tests unitaires pour JUnit dans le même ordre que le plugin JUnit pour Eclipse. En soit, c’est une bonne chose, car les tests unitaires doivent être indépendants les uns des autres.


<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-report-plugin</artifactId>
   <version>2.4.3</version>
</plugin>

Le quatrième plugin que je propose analyse le code, de manière simple. Il s’agit de taglist. Il va repérer les tags //TODO ou @todo laissés dans le code. Il est possible d’ajouter d’autres tags (par exemple @deprecated ou //FIXME) en configurant le plugin. Un conseil en passant, les //TODO sont généralement créés par les générateurs de code. Je ne les efface pas mais je remplace par des //DONE. Dans l’exemple suivant je configure explicitement 4 tags


<plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>taglist-maven-plugin</artifactId>
   <version>2.3</version>
   <configuration>
      <tags>
         <tag>TODO</tag>
         <tag>FIXME</tag>
         <tag>@todo</tag>
         <tag>@deprecated</tag>
      </tags>
   </configuration>
</plugin>

Il existe d’autres plugins comme checkstyle, cobertura, pmd, JDepend. A vos de les étudier et de voir ce qui convient à votre projet.

Benchmark des moteurs de javascript

décembre 16, 2008 by petitteckel

J’avais déjà signalé l’existence d’un benchmark des moteurs de JavaScript dans le projet webkit (sunspider), le coeur du navigateur Safari. Le résultat est un temps moyen pour effectuer différentes fonctions JavaScript. Naturellement, on peut suspecter que ce benchmark favorise un peu le navigateur Safari. Mais ce dernier n’est que 4ème sur 8. Il est même repassé derrière Opera. Google Chrome est incontestablement premier et Internet Explore dernier.

Navigateur (version) Test SunSpider (en ms)
Google Chrome (0.2.154.29) 2,6
Firefox (3.0.4) 4,8
Opera (9.62) 6,1
Safari (3.2.1) 6,4
K-Meleon (1.5.1) 14,5
SeaMonkey (1.1.13) 19,9
Flock (1.2.7) 23,0
Internet Explorer (7) 42.4

Un second benchmark est disponible sur le site du projet V8, le moteur de JavaScript du navigateur. Ici, le résultat est un nombre relatif. Le principe est que plus ce chiffre est grand plus le moteur est performant. Ceci a l’avantage d’être indépendant de l’ordinateur sur lequel s’effectue le test. Là Google Chrome écrase ses concurrents. Cependant, le classement n’est pas exactement le même.

Navigateur (version) Benchmark V8
Google Chrome (0.2.154.29) 1773
Opera (9.62) 170
Firefox (3.0.4) 141
Safari (3.2.1) 133
K-Meleon (1.5.1) 72
Flock (1.2.7) 69
SeaMonkey (1.1.13) 58
Internet Explorer (7) 33

Les différentes versions du langage JavaScript

décembre 14, 2008 by petitteckel

Cela fait plusieurs fois que je me suis posé la question s’il est correct de parler de différentes versions du langage script. Cette question m’est revenue suite à la visite du site BrowserHawk. Ce site teste les différentes capacités du navigateur web utilisé (détection du navigateur, temps de réponse). Il fournit une version langage JavaScript utilisé par le navigateur.

J’ai fais le test avec 8 navigateurs pour Windows que je considère comme « pertinents » : navigateur complet (pas une simple surcouche), mis à jour régulièrement. Ma liste est donc : Internet Explorer, Firefox, Safari, Flock, Google Chrome, K-Meleon, SeaMonkey et Opera. J’ai pris les dernières versions stables de ces navigateurs. Je suis toujours à la recherche d’autres navigateurs qui respectent les critères décrits précédemment. Voici les résultats obtenus :

Navigateur Version JS selon BrowserHawk
IE 7 1.5
Firefox 3 1.8
Safari 1.5
Flock 1.7
Google Chrome 1.8
K-Meleon 1.5
SeaMonkey 1.5
Opera 1.5

Les résultats montrent que les versions de JavaScript sont relativement récentes. Ils semblent cohérents (même résultat pour SeaMonkey et K-Meleon). Le second test est l’utilisation explicite de la version de Javascript dans une page Html comme ceci :


<script language= "JavaScript1.2">.../...</script>

ou autre manière plus standard (?)


<script type="text/javascript;version=1.2">
.../...
</script>

La seconde version de cette technique, ne fonctionne pas pour 3 navigateurs. Finalement, j’ai un gros doute sur l’interprétation de ce code. Signifie-t-il vraiment que le cette partie de script est interprétée si le navigateur supporte au moins cette version de JavaScript ? Opera ne serait-il pas un peu gros “vantard” ? Les résultats sont en fait très différents de BrowserHawk.

Navigateur BrowserHawk tag Javascript V1 tag Javascript V2
IE 7 1.5 1.3 ?
Firefox 3 1.8 1.8 1.8
Safari 1.5 1.7 ?
Flock 1.7 1.7 1.7
Google Chrome 1.8 1.7 ?
K-Meleon 1.5 1.7 1.7
SeaMonkey 1.5 1.7 1.7
Opera 1.5 2.0 1.5

Une meilleure solution serait de tester la version de JavaScript en utilisant des fonctionnalités spécifiques à chaque version. JavaScript est normalisé en tant que ECMAScript, et le site de la fondation Mozilla donne les correspondances dans le tableau qui suit. Ce qui pose la question des versions intermédiaires qui seraient spécifiées uniquement par Mozilla.

Version de Javascript Version de Firefox Version de ECMA
1.3 - ECMA 262 édition2
1.5 1.0 ECMA 262 édition3
1.6 1.5 -
1.7 2 -
1.8 3.0 -
1.9.1 3.1 -
2.0 - ECMA 262 édition4

Sur le site de Mozilla dit MDC « Mozilla Developer Center », on trouve plus ou moins difficilement les différences entre les versions successives JavaScript. Ce qui m’a permis d’écrire un script testant la version courante du JavaScript. Ce script permet de tester les version 1.0, 1.1, 1.2, 1.3, 1.5, 1.6, 1.7, 1.8 et 1.9.1. Ce script donne avec les 8 navigateurs de références.

Navigateur BrowserHawk tag Javascript V1 tag Javascript V2 test fonctionnalités
IE 7 1.5 1.3 ? 1.5
Firefox 3 1.8 1.8 1.8 1.8
Safari 1.5 1.7 ? 1.6
Flock 1.7 1.7 1.7 1.7
Google Chrome 1.8 1.7 ? 1.6
K-Meleon 1.5 1.7 1.7 1.7
SeaMonkey 1.5 1.7 1.7 1.7
Opera 1.5 2.0 1.5 1.6

Pour valider mon script, je l’ai testé avec les différentes version de Rhino. Il s’agit d’une implémentation en Java du moteur de JavaScript de Mozilla. Attention, il n’est pas utilisé dans les navigateurs Web comme Firefox mais est un reste d’un ancien projet abandonné d’un navigateur web en Java. La version Rhino 1.5R5 correspond à la version 1.5 du JavaScript, la version 1.6R7 correspond à la version 1.6 du JavaScript, et enfin 1.7R1 à la version 1.7. Ceci fonctionne correctement avec mon script. Utiliser Rhino pour exécuter du JavaScript est en effet simple. Il suffit d’utiliser la commande qui suit (test.js est mon script de test). Il existe une méthode main dans ce jar.


java -jar js.jar -f test.js

Au final, on voit qu’il existe un flou dans les différentes version du langage JavaScript mais qu’une version 1.3 ou 1.5 semble un compromis acceptable pour l’instant. Notons bien ici que je parle du coeur du langage et non de l’implémentation du DOM, l’accès aux éléments d’une page Web.

Voici le fichier test.js

function testVersion() {
var myArray = ['a', 'b', 'a', 'b', 'a'];
var res="";
var myNumber=2489.8237
var myString="eer";

//version 1.0
var version1_0=0;
if(Date.parse)
version1_0= version1_0+1;

res=res+"version 1.0 : "+version1_0+"/1 \n";

//version 1.1
var version1_1=0;
if(myArray.join)
version1_1= version1_1+1;

if(myArray.toString)
version1_1= version1_1+1;

if(myArray.reverse)
version1_1= version1_1+1;

if(myArray.sort)
version1_1= version1_1+1;

res=res+"version 1.1 : "+version1_1+"/4 \n";

//version 1.2
var version1_2=0;
if(myArray.concat)
version1_2= version1_2+1;

if(myArray.slice)
version1_2= version1_2+1;

if(myArray.pop)
version1_2= version1_2+1;

if(myArray.push)
version1_2= version1_2+1;

if(myArray.shift)
version1_2= version1_2+1;

if(myArray.splice)
version1_2= version1_2+1;

if(myArray.unshift)
version1_2= version1_2+1;

res=res+"version 1.2 : "+version1_2+"/7 \n";

//version 1.3
var version1_3=0;
if(myArray.push) {
var myArray2 = ['a', 'b', 'a', 'b', 'a'];
//V1.3 push retourne la taille du tableau.
i=myArray2.push('e','r');
if(i==7)
version1_3= version1_3+1;
}

if(myArray.splice) {
var myArray2 = ['a', 'b', 'a', 'b', 'a'];
myArray3=myArray2.splice(1,3,'z');
if(myArray3.length==3);
version1_3= version1_3+1;
}

//Boolean(new Boolean(false)) return false = 1.2 or -
//return true 1.3 or +
if(Boolean(new Boolean(false)))
version1_3= version1_3+1;

res=res+"version 1.3 : "+version1_3+"/3 \n";

//version 1.5
var version1_5=0;
if(myNumber.toFixed)
version1_5= version1_5+1;

if(myNumber.toExponential)
version1_5= version1_5+1;

if(myNumber.toPrecision)
version1_5= version1_5+1;

res=res+"version 1.5 : "+version1_5+"/3 \n";

//version 1.6
var version1_6=0;
if(myArray.indexOf)
version1_6= version1_6+1;

if(myArray.lastIndexOf)
version1_6= version1_6+1;

if(myArray.filter)
version1_6= version1_6+1;

if(myArray.forEach)
version1_6= version1_6+1;

if(myArray.every)
version1_6= version1_6+1;

if(myArray.map)
version1_6= version1_6+1;

if(myArray.some)
version1_6= version1_6+1;

res=res+"version 1.6 : "+version1_6+"/7 \n";

//version 1.7
var version1_7=0;
if(this.Iterator)
version1_7= version1_7+1;

res=res+"version 1.7 : "+version1_7+"/1 \n";

//version 1.8
var version1_8=0;
if(myArray.reduce)
version1_8= version1_8+1;

if(myArray.reduceRight)
version1_8= version1_8+1;

res=res+"version 1.8 : "+version1_8+"/2 \n";

//version 1.9.1
var version1_9_1=0;
if(myString.trim)
version1_9_1= version1_9_1+1;

if(myString.trimLeft)
version1_9_1= version1_9_1+1;

if(myString.trimRight)
version1_9_1= version1_9_1+1;

if(Object.getPrototypeOf)
version1_9_1= version1_9_1+1;

res=res+"version 1.9.1 : "+version1_9_1+"/4 \n";

print(res);

if(version1_9_1==4)
return "1.9.1";
else if(version1_8==2)
return "1.8";
else if(version1_7==1)
return "1.7";
else if(version1_6==7)
return "1.6";
else if(version1_5==3)
return "1.5";
else if(version1_3==3)
return "1.3";
else if(version1_2==7)
return "1.2";
else if(version1_1==4)
return "1.1";
else if(version1_0==1)
return "1.0";
else
return "inconnue";

}
testVersion();

Selenium RC (Remote Control)

novembre 11, 2008 by petitteckel

Selenium RC fait partie d’un ensemble d’outils de test des applications web. Parmi ces outils, il existe un outil particulièrement intéressant Selenium IDE.

Ce dernier est un plugin pour Firefox permettant d’enregistrer et de lancer des scripts de test des applications web. Le langage utilisé par défaut est propriétaire, exportable au format HTML. Mais ce plugin peut servir avantageusement de « recorder » pour la version Java. En effet, il suffit d’aller dans le menu de Selenium IDE « option\format » est de choisir le langage Java. En effet, il est parfois au début très difficile de passer du langage de commande au langage Java.

Il est possible d’écrire les tests avec Selenium à l’aide du langage Java. Un framework de test comme JUnit permet d’organiser ces tests. Au début, j’ai été tenté d’utiliser un autre framework de test que JUnit3 (JUnit4). Mais finalement le Selenium RC est une librairie de test intimement liée à JUnit3. Il est préférable de suivre le choix des concepteurs. La classe SeleneseTestCase étend la classe TestCase de JUnit. Elle contient une variable selenium de type Selenium initialisée lors de la méthode setup. Cette variable représente le navigateur web.

La classe SeleneseTestCase fournit des assertions supplémentaires commençant par verify comme verifyEquals. Quelle est la différence avec le assertEquals de TestCase ? En fait, ces méthodes font échouer le test si une assertion n’est pas respectée lors du tearDown, donc sans arrêter le script de test. Attention, ceci est « anti test unitaire », mais reste acceptable ici. En effet les tests des applications web ne sont pas en soit des tests unitaires, mais des tests de plus haut niveau.

Selenium RC se base sur un « serveur » ou un « proxy applicatif ». Pour démarrer ce serveur, le plus simple est d’utiliser le jar selenium-server*.jar, avec la commande « java -jar selenium-server.jar ». Le serveur démarre par défaut sur le port 4444. Il faut éviter de le changer car il s’agit du port qu’utilise la classe SeleneseTestCase. Dans un autre article, je décrirai comment le démarrer de manière programmatique.

Le code du test simpliste de démonstration avec le moteur de recherche Google peut être le suivant:


package com.petitteckel.seleniumdemo;

import com.thoughtworks.selenium.SeleneseTestCase;

public class GoogleTest extends SeleneseTestCase {


 public void setUp() throws Exception {
  //setUp("http://www.google.fr/", "*custom E:\\program\\mozilla.org\\SeaMonkey\\seamonkey.exe");
  setUp("http://www.google.fr/", "*iexplore");
 }


 public void testGoogle() {
  selenium.open("http://www.google.fr");
  verifyEquals(selenium.getTitle(),"Google");
  selenium.type("q", "Selenium");
  selenium.click("btnG");
  selenium.waitForPageToLoad("5000");
  verifyEquals(selenium.getTitle(),"Selenium - Recherche Google");
 }
}

La chaîne de caractères « *iexplore » représente le type de navigateur à utiliser. En effet Selenium RC pour effectuer les tests pilote les navigateurs existants. Il a donc besoin de la présence de ces logiciels. Cela pose des contraintes, par contre a l’avantage d’être fidèle à ces navigateurs. Au niveau des variables prédéfinies, il en existe 11 correspondant à des navigateurs ou des configurations de navigateurs, *iexplore pour Internet Explorer, *firefox pour Firefox, *opera pour Opera. Pour voir la liste de ces variables, il suffit de mettre *nimportquoi au niveau de cette variable et la console du serveur va la refuser et afficher la liste des variables possibles. L’utilisation de ces variables devrait permettre l’utilisation des navigateurs sans les reconfigurer, dans la pratique cela ne marche pas très bien, voire pas du tout. La solution de secours est d’utiliser la chaîne *custom.

Il faut dans ce cas faire suivre *custom du chemin exact du navigateur. Au niveau du navigateur, il faut préciser que le proxy est localhost port 4444. Cela fonctionne avec tous les navigateurs installés sur mon poste Windows (de Flock à Safari en passant par Google Chrome). Mais cela risque de poser un problème si la connexion vers l’application testée passe également par un proxy.

Enfin, il est possible d’utiliser Maven, pour la gestion des dépendances dans le projet Java. Je mets dans l’exemple plus bas les dépendances pour la version 1.0-beta-1 (la dernière). Par défaut, le jar junit3.8.1.jar est mis dans le projet. Ceci confirme bien ce que j’ai expliqué un peu avant.


 <dependency>
  <groupId>org.openqa.selenium.client-drivers</groupId>
  <artifactId>selenium-java-client-driver</artifactId>
  <version>1.0-beta-1</version>
 </dependency>
 <dependency>
  <groupId>org.openqa.selenium.core</groupId>
  <artifactId>selenium-core</artifactId>
  <version>1.0-beta-1</version>
 </dependency>

Au final, je trouve que Selenium RC est un outil intéressant mais pas encore stabilisé, donc difficile à généraliser au niveau d’une entreprise.

L’outil d’automatisation Maven2

novembre 8, 2008 by petitteckel

Maven est un outil dont la notoriété et l’utilisation augmente dans le monde Java. Son utilisation croit également dans le cadre de l’entreprise. D’autre part, son utilisation se répand largement dans les projets libres. Il facilite largement la tâche de recompiler un projet libre à partir du code source. Je tenterai ici d’expliquer pourquoi.

Il s’agit notamment d’un outil d’automatisation des tâches, même si ce point de vue est un peu réducteur. Il remplace avantageusement Ant pour la partie automatisation. Dans cette présentation, je me limite à Maven2. En effet, Maven1 était un Ant un peu amélioré sans intérêt réel maintenant.

Maven comme Ant permettent d’automatiser les tâches dans un projet Java, comme la compilation, la génération d’archive, de rapport. Dans Ant, on définit certaines tâches, cela ressemble un peu à de la programmation. C’est donc bien adapté à l’état d’esprit d’un développeur. Mais finalement, on a l’impression redéfinir la roue à chaque fois et les scripts Ant peuvent devenir très longs, peu normalisés et difficiles à comprendre par une personne étrangère à l’équipe projet. Quant à Maven, il se base sur un principe complètement différent de Maven. On ne déclare pas de tâches, elles sont prédéfinies. C’est assez logique. Un projet Java doit être compiler, il devrait être testé, il doit permettre la création d’une archive comme un jar ou un war pour être utilisé facilement par d’autres projets. Donc la commande « mvn test » exécute les tests unitaires, « mvn package » génère l’archive associée au projet, et ceci pour tous les projets utilisant Maven. Il est possible de générer avec Maven, les rapports associés aux outils de qualité comme checkstyle et cobertura.

Comment fonctionne alors ce magique outil Maven ? Le développeur définit dans le fichier pom.xml la structure du projet. Je ne déclare pas les actions à effectuer sur le projet mais comment est structuré le projet. Cette approche déclarative n’est pas forcément la plus proche de l’état d’esprit du développeur mais est ici beaucoup plus efficace. Un autre point diminue fortement la taille du fichier pom.xml, Maven se base sur des conventions. Le code source se trouve par défaut dans le répertoire src/main/java. Il est toujours possible de le placer ailleurs mais finalement il est mieux de suivre les conventions. Le seul cas où il reste utile de surcharger les conventions est lorsqu’on reprend d’anciens projets archivés sous CVS. Le déplacement d’un fichier avec CVS fait perdre l’historique.

Maven gère également les dépendances entre projets avec les versions. Un projet java classique va utiliser le framework de test Junit (version 3 ou 4), la librairie log4j pour la gestion des traces techniques. On déclare explicitement les dépendances et leurs portées (test, compile, runtime). Ceci est sans doute une réponse provisoire au grand désordre qu’est la non gestion des dépendances dans le monde Java (et je suis très poli ici : c’est le vrai B***).

Il demeure cependant quelques problèmes lors de l’utilisation de Maven. Le premier est le manque d’intégration dans Eclipse. Ce problème était important il y a quelques temps. Maintenant, il existe deux plugins m2eclipse et q4e. J’utilise le premier dans mon activité professionnelle, ceci de plus en plus. Le second q4e est un projet Google. Il apparaît plus ambitieux que m2. Il propose notamment une vue graphique des dépendances. Maintenant, l’installation par le site update ne fonctionne pas. Je ne le conseille pas un premier temps et je vous propose m2.

Les plugins ne font pas tout. Il existe un manque dans Eclipse au niveau de la hiérarchie des projets. Tous les projets Eclipse sont au même niveau. Tandis que Maven autorise des hiérarchies de projets. En fait ceci est imposé par Maven du fait qu’un projet Maven correspond à un seul artefact (pas deux ou plusieurs). Ceci risque d’engendrer un nombre important de projets Eclipse. Notons qu’Eclipse n’a pas de notion de portée des dépendances. Donc si vous utiliser Junit, une librairie Junit*.jar apparaît dans la liste des dépendances alors qu’avec Maven on peut indiquer que cette dépendance ne concerne que la partie des tests, et non l’utilisation de l’archive dans un autre projet.

Autre point délicat, je découvre régulièrement des petits bugs dans les plugins Maven de métriques et de qualité du code.

Un nom de domaine pour la Flandre ?

novembre 1, 2008 by petitteckel

Le ministre-président Kris Peeters veut créer un nom de domaine de premier niveau (TLD pour Top Level Domain) pour la Flandre. Un TLD est une extension comme le .be pour la Belgique ou le très courant .com qui apparaît dans les applications de l’internet comme l’adresse web ou l’adresse mail. Pour un pays ont parle de ccTLD (country code TLD) et pour un nom de domaine ouvert à tous de gTLD (generic). Un troisième groupe forme les sTLD pour les noms de domaines limités à une communauté, dits « commandités »

L’ICANN l’association qui gère les noms de premier niveau avait une politique très prudente de ces noms. Les pays ont d’office un nom de premier niveau sur deux lettres suivant la norme ISO 3166-1 comme le .be ou le .fr. Mais, il n’y avait rien pour les subdivisions des pays ou les grandes métropoles…

Mais en 2005, l’ICANN a autorisé le sTLD .cat pour la communauté catalane (langue et culture, par pour la région espagnole). Suite à cette décision sans doute un peu hasardeuse, de nombreuses régions se sont mises à rêver de leur propre nom de domaine de premier niveau. Une association milite pour un .bzh pour la Bretagne. D’autres initiatives font la promotion d’un .sco pour l’Ecosse et d’un cym pour le Pays de Galles. Les peuples celtiques abusent-ils de l’alcool ?

Cette année, l’ICANN a annoncé une certaine libéralisation des noms de domaine de premier niveau pour un démarrage effectif en 2009. Juste un petit détail supplémentaire, le budget est estimé à 100 000 euros. En fait d’autres sources parlent d’une somme un peu plus élevée : 200 000 Dollars américains.

Quel est vraiment l’intérêt d’un tel nom ? Les noms de domaine génériques (ouvert à tous) lancé vers 2001 comme le .biz ou le .info ont eu des succès mitigés. Des sTLD comme le .mobi ou le .tel finissent par être ouvert à tous. Je pense que pour les grandes régions cette idée n’est pas si farfelue qu’elle n’y paraît. Maintenant, quel nom de domaine pour ma région ? Le .vl est libre mais ce nom n’est pas autorisé par le règlement de l’ICANN (la Flandre n’est pas un état indépendant). Les propositions sont .vla .vln .vlaanderen .fla…

Il est beau mon petit lion...

Il est beau mon petit lion...

Les outils de test commerciaux iMacros et eValid

octobre 15, 2008 by petitteckel

Concernant les tests des applications web, je me suis posé la question s’il est possible de tester des applets. Cette problématique pourrait être généralisée aux autres technologies comme Flash Silverlight. Les outils libres ne semblent pas répondre à cette question. Je me suis tourné vers des outils commerciaux, iMacros et eValid.

IMacros existe sous forme de plugin pour navigateur web en freeware, également pour une utilisation commerciale. Ce plugin existe pour les navigateurs Firefox et Internet Explorer. Les tests sont écrits avec un langage de script spécifique. Il existe un enregistreur. Le site d’Iopus déclare que iMacros supporte les technologies Flash, Flex, Java, Silverlight. Dans la pratique le freeware ne semble pas fonctionner correctement, et le principe semble de repérer au pixel près la position du curseur. Est-ce réellement portable.

Le second outil qui peut répondre à ce problème est eValid. Je n’ai pas pu réellement le tester.