Archive for août, 2008

Hacking Maven

À un niveau de technique, on ne sait plus si ce qu’on fait est utile ou pas. C’est le cas aujourd’hui. Donc cela va parfaitement pour le jinutilitaire.

J’utilise Maven pour organiser mes développements. Pour ces projets, j’utilise plein d’autres projets bibliothèques, des dépendances que j’inscris comme telles dans Maven, dans ce qu’on appelle le pom.xml.

Mais je n’arrive pas à tout faire avec Maven ; pour les déploiements par exemple j’utilise Ant. Il faut que je re-indique alors mes projets bibliothèques. C’est un peu fastidieux.

Il existe (si vous suivez) un autre utilitaire pour indiquer ces dépendances, qui s’appelle Ivy, qui s’associe bien à Maven, mais pour les dependances il faut tout re-écrire C’EST LA BARBE !

J’ai cherché mille choses, posé mille questions sur les forums, rien.

Et j’ai fini par me décider à écrire mon petit utilitaire (cela faisait longtemps), pour transformer automatiquement (ou presque) le jargon maven en jargon ivy, à partir du code source de Maven lui même et son javadoc.

Et l’étonnement m’a pris, cela est quasi-facile !

Voici le programme qui m’affiche les dependencies d’un pom.xml en deux coups de cuillère à pot (quasi mieux que Maven lui même, d’ailleurs) :

package jinutilitaire.lecoinmaven;

import java.io.FileReader;
import java.util.List;
import org.apache.maven.model.Dependency;
import org.apache.maven.model.Model;
import org.apache.maven.model.io.xpp3.MavenXpp3Reader;

public class Coin 
{
    public static void main(String[] args) throws Exception
    {
      MavenXpp3Reader xppread;
      Model model;
      List dependencies;
      
      xppread = new MavenXpp3Reader();
      model = xppread.read(new FileReader("/ici/le/path/pour/le/pom.xml"));
      dependencies = model.getDependencies();
      for (Object o : dependencies)
      {
        Dependency dep;
        
        dep = (Dependency)o;
        System.out.printf(
                "%n", 
                dep.getGroupId(), 
                dep.getArtifactId(),
                dep.getVersion());
      }
    }
}

Hahurissant ! 3 lignes de code ! Dans l’univers d’aujourd’hui c’est exceptionnel ! En plus le code de Maven semble super bien conçu, facile à comprendre, bien qu’il n’y ait pas beaucoup de doc… donc un Bon Point Pour Maven.

Pour que ça marche inclure le $MAVEN_HOME/lib/maven-2.0.9-uber.jar dans le classpath.

Laissez un commentaire

Tester Hello Swing après avoir dormi

L’idée naturelle pour tester notre Hello Swing est de se dire : Le logiciel de test va lancer l’appli puis regarder si ça s’est affiché. Nous allons essayer de la faire.

Mais si l’on comprend que l’on va afficher et immédiatement après regarder s’il y a quelque chose, cela va foirer : entre une commande d’affichage, et l’affichage lui même, il y a toujours un délai de réaction.

Mais combien de temps ? En général, pas très long. On peut considérer que, si au bout de 1 seconde, rien ne s’est affiché, c’est qu’il y a un problème quelque part.

Voilà pourquoi, après avoir lancé la commande d’affichage, nous allons attendre, nous endormir, 1 petite seconde, et alors seulement regarder si l’affichage a eu lieu.

Voici le code :

  public void testApparitionDeLaFenêtre() throws Exception
{ Object oreiller; Frame[] apparues; HelloWorld.main(null); oreiller = new Object(); synchronized (oreiller) { oreiller.wait(1000); } apparues = Frame.getFrames(); Assert.assertEquals(1, apparues.length); apparues[0].dispose(); }

Nous testons simplement qu’au bout de 1 seconde il y a une fenêtre.

Cette forme simple n’oblige à aucune modification du code d’origine.

Mais elle est fragile devant de possibles évolutions : si notre appli est utilisée dans le cadre d’autres applis, par exemple ? (il y aurait alors un nombre indeterminé de fenêtres).

Pour exécuter le test, cliquez ici : launch.jnlp (ouvrez au préalable la console JWS pour voir le résultat).

pour avoir les sources et le reste, cliquez ici.

Laissez un commentaire