Articles avec #maven tag

Publié le 6 Mars 2015

Pour compiler uniquement un module (ou une liste de modules) il faut utiliser l'option -pl (project list):

mvn test -pl web

L'option -am (also make) peut aussi être intéressante car elle permet de compiler les modules dont dépendent ceux spécifiés avec -pl:

mvn test -pl web -am

Voir les commentaires

Rédigé par Bliz

Publié dans #Maven

Repost 0

Publié le 9 Octobre 2013

Avec maven les tests se lancent avec la commande :

mvn clean test

mais cela va exécuter tous les tests du projet.

Heureusement on peut se limiter à une seul classe de test en utilisant la propriété test:

mvn clean test -Dtest=PurchaseTest

et même à un seul cas de test, c'est à dire une seule méthode d'une class de test:

mvn clean test -Dtest=PurchaseTest#testNotEnoughCredit

Et en bonus on peut même utiliser le caractère joker '*' pour ne sélectionner qu'une serie de tests:

mvn clean test -Dtest=Purchase*

Voilà tout est expliqué en detail ici:

http://maven.apache.org/surefire/maven-surefire-plugin/examples/single-test.html

Voir les commentaires

Rédigé par Bliz

Publié dans #Maven

Repost 0

Publié le 12 Août 2013

J'utilise quotidiennement maven et le plus souvent en ligne de commande et s'il y a un reproche qu'on peut faire sur la forme (je ne parle pas du fond et ni de la philosophie maven mais uniquement de la forme), c'est bien que tout cela est terne.

Heureusement il est facile d'ajouter un peu de couleur dans un terminal en fonction les niveaux de logs de la sortie maven. Après quelques recherches je suis tombé sur la définition d'un alias 'mvn' qui ajoute la couleur en utilisant sed avec les codes d'échapement de couleur.

Donc si vous êtes pressés vous pouver l'installer facilement avec la commande suivante:

# curl https://raw.github.com/builddoctor/maven-antsy-color/master/mvn >> ~/.bash_aliases
# . ~/.bashrc

Et voilà c'est tout de suite beaucoup plus gai!

Comme l'idée n'est pas de moi voici où trouver toutes les infos : https://github.com/builddoctor/maven-antsy-color

Sinon j'ai trouvé la sortie un peu trop verte (toutes les lignes INFO sont en vert) et apporté une petite correction sur les lignes en WARNING.

Donc voici ma version qui reste très proche de l'original:

# thanks to:  http://blog.blindgaenger.net/colorize_maven_output.html
# and: http://johannes.jakeapp.com/blog/category/fun-with-linux/200901/maven-colorized
# Colorize Maven Output

alias maven="command mvn"

color_maven() {

maven $* | sed -e 's/Tests run: \([^,]*\), Failures: \([^,]*\), Errors: \([^,]*\), Skipped: \([^,]*\)/Tests run: ^[[1;32m\1^[[0m, Failures: ^[[1;31m\2^[[0m, Errors: ^[[1;33m\3^[[0m, Skipped: ^[[1;34m\4^[[0m/g' \
   -e 's/\(\[WARN\].*\)/^[[1;33m\1^[[0m/g' \
   -e 's/\(\[WARNING\].*\)/^[[1;33m\1^[[0m/g' \
   -e 's/\(\[INFO\].*\)/^[[1;37m\1^[[0m/g' \
   -e 's/\(\[ERROR\].*\)/^[[1;31m\1^[[0m/g' \
   -e 's/\(BUILD FAILURE.*\)/^[[1;31m\1^[[0m/g' \
   -e 's/\(FAILURE!.*\)/^[[1;31m\1^[[0m/g' \
   -e 's/\(BUILD SUCCESS.*\)/^[[1;32m\1^[[0m/g' \
   -e 's/\(SUCCESS.*\)/^[[1;32m\1^[[0m/g' 

}

alias mvn=color_maven

Voir les commentaires

Rédigé par Bliz

Publié dans #Maven

Repost 0

Publié le 9 Janvier 2013

Sur mon projet nous utilisons xmlbeans pour générer des fichiers sources. Malheureusement ces fichiers ne sont pas générés dans target/generated-sources mais directement sous src/main/java (dans un package particulier bien sûr).

Il faut donc ajouter la suppression de ce répertoire à la phase de clean. Pour ceci il faut configurer le plugin maven-clean-plugin de la façon suivante:

<plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-clean-plugin</artifactId>
 <configuration>
  <filesets>
   <fileset>
    <directory>src/main/java/com/patatos/monpackage/</directory>
    <followSymlinks>false</followSymlinks>
    <excludes>
     <exclude>*.java</exclude>
    </excludes>
   </fileset>
  </filesets>
 </configuration>
</plugin>

Le bloc <excludes> est optionnel mais il permet de garder les classes se trouvant directement dans monpackage tout en supprimant tous les sous-packages. 

S'il est absent cela effacera directemet monpackage complet. Alternativement on pourrait utiliser un bloc <includes> pour ne spécifier que les fichiers à effacer.

Plus de détails sur la configuration des filesets sur la page du maven-clean-plugin.

Voir les commentaires

Rédigé par Bliz

Publié dans #Maven

Repost 0

Publié le 20 Novembre 2012

Aujourd'hui j'ai un petit soucis dans mes pom.xml et j'ai besoin de vérifier la valeur des propriétés maven, telles qu'elles sont interprétées par maven.

Un genre de println à placer dans le pom.xml serait bien pratique, mais comme on est dans un modèle déclaratif c'est pas aussi simple que ça.

Heureusement le plugin maven-help-plugin arrive à la rescousse. En effet on peut l'utiliser pour afficher la valeur d'une propriété sans exécuter toutes les étapes de build. Par exemple la commande suivante permet de vérifier la valeur de la propriété project.version

mvn org.apache.maven.plugins:maven-help-plugin:evaluate -Dexpression=project.version

pour vérifier une autre valeur de propriété il suffit de changer le nom de la propriété dans la ligne de commande.

Voir les commentaires

Rédigé par Bliz

Publié dans #Maven

Repost 0

Publié le 22 Août 2012

Alors voilà le problème:

J'ai un projet maven avec certaines que je n'utilise que lors de la phase d'intégration. Ces classes me fournissent des points d'entrées en ligne de commande pour tester directement les interactions avec d'autres systèmes.

Bref je ne veux pas inclure ces sources dans mon jar en production mais par contre j'en ai besoin en phase d'intégration.

Ces sources sont exclues par défaut du projet maven avec la configuration suivante:

<build>
 <plugins>
  <plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-compiler-plugin</artifactId>
   <configuration>
    <excludes>
     <exclude>com/over-blog/patatos/integration/**</exclude>
    </excludes>
   </configuration>
  </plugin>
 </plugins>
</build>

Ensuite je défini un profile particulier que j'appelle "intégration" et dans lequel je fais un include des ces sources:

<profiles>
 <profile>
  <id>integration</id>
  <build>
   <plugins>
    <plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-compiler-plugin</artifactId>
     <configuration>
      <includes>
       <include>com/over-blog/patatos/integration/**</include>
      </includes>
     </configuration>
    </plugin>
   </plugins>
  </build>
 </profile>
</profiles>

Et bien contre toute attente ce méchanisme ne fonctionne pas. Pourquoi ? En quelque sorte on peut dire que l'exclude l'emporte sur l'include.

Pour résoudre ce problème il faut explicitement indiquer qu'on ne veut pas d'exclusion dans le profile "integration".

<profiles>
 <profile>
  <id>integration</id>
  <build>
   <plugins>
    <plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-compiler-plugin</artifactId>
     <configuration>
      <excludes>
       <exclude>none</exclude>
      </excludes>
     </configuration>
    </plugin>
   </plugins>
  </build>
 </profile>
</profiles>

 

 

Voir les commentaires

Rédigé par Bliz

Publié dans #Maven

Repost 0

Publié le 10 Juillet 2012

Un petit bug étrange ce matin avec maven:

J'ai un projet avec des tests unitaires et ils passent nickel sous Eclipse (yes!).

J'utilise maven pour le build et là je tombe sur l'erreur suivante:

java.lang.Exception: Test class should have exactly one public constructor
at org.junit.runners.BlockJUnit4ClassRunner.validateOnlyOneConstructor(BlockJUnit4ClassRunner.java:136)
at org.junit.runners.BlockJUnit4ClassRunner.validateConstructor(BlockJUnit4ClassRunner.java:125)
at org.junit.runners.BlockJUnit4ClassRunner.collectInitializationErrors(BlockJUnit4ClassRunner.java:114)
at org.junit.runners.ParentRunner.validate(ParentRunner.java:269)
at org.junit.runners.ParentRunner.<init>(ParentRunner.java:66)
at org.junit.runners.BlockJUnit4ClassRunner.<init>(BlockJUnit4ClassRunner.java:59)
at org.junit.internal.builders.JUnit4Builder.runnerForClass(JUnit4Builder.java:13)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at org.apache.maven.surefire.junit4.JUnit4TestSet.<init>(JUnit4TestSet.java:45)
at org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96)
at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209)
at org.apache.maven.surefire.Surefire.run(Surefire.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)

D'abord je ne comprends pas : ma classe de test ressemble à tout ce qu'il y a de plus normal et passe nickel sous Eclispe. Bizarre!

En fait cela vient de la configuration du plugin surefire de maven qui par défaut considère toutes les classes de test qui commencent par Test ou se termine par Test. OK mais cela comprend les inner class. Et c'est là que le bas blesse.

Il y a effectivement une inner class anonyme dans mon test et lors de la compilation le nom de cette class est TestCaseNormal$1.class et pour le plugin surefire il s'agit d'une classe de test comme une autre.

Et la solution: il suffit de demander à maven d'exclure les inner class des tests de la manière suivante:

<project>
 [...]
 <build>
  <plugins>
   <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.12</version>
    <configuration>
     <excludes>
      <exclude>**/*$*</exclude>
     </excludes>
    </configuration>
   </plugin>
  </plugins>
 </build>
 [...]
</project>

Voir les commentaires

Rédigé par Bliz

Publié dans #Maven

Repost 0

Publié le 21 Mai 2012

Dans un précédent article sur la génération d'un jar exécutable avec Maven, je proposais d'inclure toutes les dépendances du projet à l'intérieur du jar généré. ça marche mais le jar généré risque d'être un peu gros.

Voici donc une autre solution qui consiste à préciser le classpath dans le manifest du jar, mais toutes les libs devront être présentes lors de l'exécution.

 <build>
    <plugins>
      <plugin>
         <artifactId>maven-jar-plugin</artifactId>
         <configuration>
           <archive>
             <manifest>
               <addClasspath>true</addClasspath>
               <classpathPrefix>lib/</classpathPrefix>
               <mainClass>com.over-blog.patatos.App</mainClass>
             </manifest>
           </archive>
         </configuration>
      </plugin>
    </plugins>
  </build>

Pour plus d'info, voir la documentation Maven: http://maven.apache.org/shared/maven-archiver/examples/classpath.html

Voir les commentaires

Rédigé par Bliz

Publié dans #Maven

Repost 0

Publié le 20 Février 2012

Sur mon projet nous utilisons Maven pour effectuer la compilation. Maven permet de télécharger automatiquement toutes les dépendances nécessaires à la compilation du projet.

Cependant aujourd'hui lors de l'ajout d'une nouvelle librairie le téléchargement automatique n'a pas fonctionné car la librairie en question n'est pas disponible en ligne.

Comme il s'agit d'une phase de test et d'investigation je ne souhaite pas télécharger la librairie sur le dépôt officiel du projet.

Il me reste une solution installé la libraire localement pour que Maven la trouve lors de la compilation.

Cette opération s'effectue avec Maven en tapant la commande suivante:

mvn install:install-file -Dfile=<lib.jar> -DgroupId=<groupId> -DartifactId=<artifactId> -Dversion=<version> -Dpackaging=<packaging>

Il faut remplacer chaque paramètre entre < et > par la valeur appropriée qui dépend de la lib à installer.

Voir les commentaires

Rédigé par Bliz

Publié dans #Maven

Repost 0

Publié le 11 Octobre 2011

On peut simplement désactiver un profile maven avec l'option -P en faisant précéder le nom du profile par un !

ce qui donne par exemple:

mvn clean install -P\!monProfile

Le backslash sert simplement à protéger le ! lors de l'interpretation de la ligne de commande, afin d'éviter l'erreur suivante:

bash: !monProfile: event not found

Voir les commentaires

Rédigé par Bliz

Publié dans #Maven

Repost 0