If you have the following error when launching a Maven command, for example « mvn install »:
Could not find the main class: org.codehaus.plexus.classworlds.launcher.Launcher
Your are probably using a Maven 2 configuration for a Maven 3 usage. Delete your global variable M2_HOME and it should work. You can use M3_HOME instead to select the folder for the « repository » of dependencies, and the emplacement of the configuration file settings.xml.
Lorsque vous lancez une commande Maven (par exemple « mvn install ») et que vous obtenez l’erreur suivante :
Could not find the main class: org.codehaus.plexus.classworlds.launcher.Launcher
ou en français :
Erreur : impossible de trouver ou charger la classe principale org.codehaus.plexus.classworlds.launcher.Launcher
Pas de panique ! La solution la plus probable est que vous utilisez une configuration de Maven 2 pour utiliser Maven 3.
Avec Maven 3, il faut enlever le variable d’environnement M2_HOME : et normalement ça marche ! Si besoin, il est possible d’utiliser M3_HOME pour préciser l’emplacement pour déployer / récupérer les dépendances (dossier « repository ») et où placer le fichier de configuration utilisateur « settings.xml ».
Maven failed during a build whit the following error:
The system is out of resources.
Consult the following stack trace for details.
java.lang.OutOfMemoryError: PermGen space
Add the environment variable MAVEN_OPTS: -Xms512m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=512m
Lors d’un build, Maven s’arrête en failure et s’explique par l’erreur suivante :
The system is out of resources.
Consult the following stack trace for details.
java.lang.OutOfMemoryError: PermGen space
Ajouter la variable d’environnement MAVEN_OPTS : -Xms512m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=512m
Sous Windows, le nom de vos dossiers peut contenir des espaces, comme par exemple le bien connu « C:\Program Files\ »). Certains logiciels, n’aiment pas trop cela. Maven par exemple ! Ah non, il n’aime pas ça du tout ! Un chemin avec espace dans le fichier settings.xml, et c’est le drame ! Et ce n’est malheureusement pas le seul.
Heureusement, il existe une parade pour éviter de renommer ses dossiers, ou de déplacer ses fichiers. Il suffit d’utiliser le shortened name du chemin au lieu de son nom courant, ce que l’on pourrait traduire par nom raccourci. Pour connaître ce shortened name :
cmd, ou alors ouvrez C:/Windows/system32.cmd.exe,cd C:\),dir /x
Trouver le shortened name d'un dossier
Cela devrait vous afficher le shortened name. Pour « C:\Program Files\ », cela devrait normalement être « PROGRA~1 ».
On souhaite préciser le chemin du JDK que la JVM (machine virtuelle Java) utilisera pour faire tourner Eclipse. Certains plugins comme M2Eclipse (le plugin Maven d’Eclipse) en ont parfois besoin car ils utilisent le JDK et non le JRE Java, et c’est donc un moyen de s’assurer que la configuration est bien faites.
Voici un exemple de message d’erreur qui vous incite à ajouter cette option dans le fichier eclipse.ini :
Le JDK étant plus large que le JRE, vous pouvez effectuer cette opération sans crainte.
Instinctivement pour tester l’égalité de deux variables sous Maven, moi j’écrirai :
<j:if test="${var1 == var2}">
<echo message="var1 égale var2" />
</j:if>
Mais visiblement sous Maven, ça ne marche pas comme ça ! Le code suivant renverra un résultat pour le moins aléatoire. Du coup, en réfléchissant et en parcourant la Toile (qui est très pingre à ce sujet), je me suis mis à écrire :
Continuer la lecture
Encore un petit petit peu de Maven pour aujourd’hui. Lorsque j’ai fait mes recherches sur la dates, j’ai cherché quelques temps (sans succès) au niveau des variables d’environnement. Du coup, je sais que, sous Maven, pour récupérer les variables d’environnement (JAVA_HOME, M2_HOME, …) il faut préciser le nom du tableau permettant de les récupérer :
<property environment="env" />
Puis d’utiliser : ${env.JVA_HOME}.
Dans le même esprit, le Maven Properties Guide fournit une liste des variables Maven prédéfinies. Voilà qui peut être utile !
Décidement, en ce moment, je m’amuse avec les dates ! Aujourd’hui c’est au tour d’Ant de passer au crible. Dans le fichier de configuration de Maven, voici ce que j’utilise :
<ant:tstamp>
<format property="dateDuJour" pattern="yyyy-MM-dd" />
</ant:tstamp>
<echo message="Nous somme le : ${dateDuJour}"/>
Ce qui affiche : 2010-07-08.
En lisant un article sur le site de Gadberry (article parlant des dates avec Ant) et surtout la doc Ant sur tstamp, on peut voir qu’on peut bien sûr préciser un format comme on veut (ex : yyyy-MM-dd hh:mm), ou utiliser les formats prédéfinis :
<ant:tstamp />
<echo message"${DSTAMP}" />
<echo message"${TSTAMP}" />
<echo message"${TODAY}" />
Ce qui affiche : 20100708, 1715 et 2010 07 08.
Dans la société où j’effectue mon stage actuellement, on utilise Maven. Je ne vais pas détailler maintenant ce « truc » parce que j’en serai bien incapable mais en gros Maven est un projet d’Apache qui fournit : des normes, des méthodes de build automatisées et peut-être d’autres choses. Hum, on va dire ça comme ça !
On utilise Maven avec Ant pour builder, et on peut donc utiliser toutes les commandes d’Ant dans les fichiers de configuration de Maven, enfin en théorie. Une des méthodes que l’on utilise fréquement sous Maven est la méthode deploy. Cette méthode copie les jar générés (oui, oui, je fais du Java !) à l’endroit que l’on a configuré, généralement en utilisant copy d’Ant. Du coup, moi ce qu’on m’a demandé de faire c’est de créer une méthode deployProd qui copie les jar sur le serveur distant de production. L’idée est donc d’utiliser scp (la commande de copie en SSH en shell) et non plus copy. Les problèmes commencent à ce niveau là et sont sûrement dû au fait que je travaille sous Windows et non sous Linux…
Avant de commencer : j’utilise Maven 1 et je crois qu’on utilise une architecture assez bizarre, mais je n’ai pas suffisement d’expérience pour aller plus loin.
Continuer la lecture
