Discussion :

[vinou92340]

Bonjour,

Je me pose une question, j'ai décidé de me mettre à maven. J'ai récupéré une commande pour créer un projet struts 2 sur le site de struts. Voici cette commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
mvn archetype:generate -B -DarchetypeGroupId=org.apache.struts -DarchetypeArtifactId=struts2-archetype-blank -DarchetypeVersion=2.3.4.1 -DgroupId=org.lola -DartifactId=Test

Or, je voudrai aussi utiliser hibernate. De ce fait, j'ai rajouté la dépendance suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate</artifactId>
            <version>3.0.5</version>
            <scope>compile</scope>
        </dependency>

avec ce repository :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
<repository>
        <id>maven-nuxeo</id>
        <name>Maven Nuxeo Repository</name>
        <url>https://maven.nuxeo.org/nexus/content/groups/public/</url>
        <layout>default</layout>
 </repository>

Il est à noter que quand je mets : http://repository.jboss.org/maven2, j'ai une erreur d'accès interdit. De ce fait, j'ai cherché sur internet et j'ai trouvé un autre repository. Si vous avez un autre repository avec un hibernate en version actuelle, je suis preneur .

Bref, quand je fais un clean install, j'obtiens bien la librairie hibernate dans la liste "Maven Dependancies". Mais n'y a t il pas moyen d'obtenir aussi les fichiers xml en rapport avec hibernate via maven et que ceux ci soient mis en place au bon endroit ?

Je constate aussi que dans mon projet, je me retrouve avec des dossiers en double.
Un exemple de package :
src/main/java/org.lola.example
qui apparait en dessous sous forme de dossier:
src/main/java/org/lola/example/
Est ce normal ?

De plus est ce que la partie src/test est obligatoire ?

Je vous remercie d'avance pour votre aide et la prise en considération de mes questions .

Cordialement,

Vinz le Newbie de Maven

[Philippe Bastiani]

Difficile de trouver l'archetype qui va bien...

Tu peux démarrer un projet hibernate avec un autre archetype pour voir la structure d'un tel projet ! Puis, mixer les 2...

Note: AppFuse propose des solutions complètes pour démarrer un projet global... Peut-être y trouveras tu ton bonheur!

M2E te permet de trouver les dépendances en quelques clics. Sinn, tu as des site comme celui-ci MavenCentral (c'est le site par défaut pour maven, et tu pourras constater que hibernate est dispo.. donc inutile de rajouter un repository jboss ou autre). Tu as aussi ce site).

Concernant les fichies xml qui te manquent: quels sont-ils ? mapping ? config ? Celà n'a aucun rapport avec Maven... Comme dit plus haut: le mieux, pour toi, est de générer un applis purement hibernate avec un archetype...

La partie test n'est pas obligatoire... mais, pourquoi ne pas commencer tout de suite ?

a+
Philippe

[vinou92340]

Merci pour votre réponse .

Je vais peut être tenter l'utilisation d'archétypes pré définis mais le problème est qu'il y a déjà 250 fichiers en plus de ceux nécessaires fournis dans ces archétypes.

Autre question à laquelle vous allez surement répondre. Imaginons que je crée un module java (déploiement de type jar) pour tout ce qui est interaction avec la base de donnée, que je le mets dans les dépendances d'un module web (war) et que pour finir je crée un projet père qui est obligatoirement déployable en type "pom" et dont le fichier pom contient les deux modules précédents. Quand j'essaye d'exporter mon fichier via l'interface export>web>war, ce n'est pas possible. Est ce normal ? (j'arrive à le faire au travail et je me demande comment faire).


Merci d'avance

Vinz

PS: pourriez vous m'expliquer globalement ^^ à quoi sert la partie test svp.

[romaintaz]

Autre question à laquelle vous allez surement répondre. Imaginons que je crée un module java (déploiement de type jar) pour tout ce qui est interaction avec la base de donnée, que je le mets dans les dépendances d'un module web (war) et que pour finir je crée un projet père qui est obligatoirement déployable en type "pom" et dont le fichier pom contient les deux modules précédents. Quand j'essaye d'exporter mon fichier via l'interface export>web>war, ce n'est pas possible. Est ce normal ? (j'arrive à le faire au travail et je me demande comment faire).

Ca ne marche pas tout à fait comme ça. Ton étape du déployable par un pom est inutile et fausse. Un projet de type pom est un "méta-projet", qui n'a aucun livrable normalement, à part le pom.xml lui-même. Alors oui, on peut très bien générer un livrable via un projet pom (en utilisant les archetypes par exemple), mais c'est contraire à l'esprit de Maven.
Dans ton cas, c'est plutôt ton projet WAR qui sera le livrable. Tu auras du coup une architecture comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
mon-projet
  +- pom.xml                    [le pom.xml parent, de type POM]
  +- ma-librairie
  |    +- pom.xml               [le pom.xml de la librairie, de type JAR]
  |    +- src/main/java         [les sources de l'application]
  |    +- src/main/resources    [les ressources de la librairie]
  |    +- src/test/java         [les sources de tests de l'application]
  |    +- src/test/resources    [les ressources de tests de l'application]
  +- mon-web
       +- pom.xml               [le pom.xml du projet web, de type WAR et dépendant de ma-librairie.jar]
       +- src/main/webapp       [les ressources du projet web]

PS: pourriez vous m'expliquer globalement ^^ à quoi sert la partie test svp.

A écrire son code de test, tout simplement
Grosso-modo, dans une application, on écrit 2 types de code (pour faire simple) : le code de "production", c'est-à-dire l'application elle-même, et le code de test. Ce dernier (basé sur du JUnit, TestNG, ou encore plein d'autres choses) a pour rôle de vérifier que le code de production réalise bien ce que l'on attend de lui. Comme c'est du code, il reste exécutable et permet ainsi de tester ton application en continu, via par exemple un serveur d'intégration continue (cf. ma signature sur Hudson par exemple). Sans test, ton code peut marcher, mais tu ne peux pas en avoir la certitude (sans compter qu'il peut fonctionner, mais ne pas répondre aux vrais besoins).
Un exemple tout bête. Prennons une méthode qui fait des divisions :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public static double divise(double a, double b) {
    return a / b;
}

Là, tu écris ton code de test :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
@Test
public void test_division() {
    assertEquals(2, MaClass.divise(8, 4));
    assertEquals(-3, MaClass.divise(-9, 3));
}

Et ainsi de suite. L'idée étant ainsi de pouvoir aussi tester des cas limites. Que se passe-t-il si j'appelle MaClass.divise(42, 0); ? Sans mes tests, peut-être que je m'apercevrait de mon erreur qu'une fois l'application en production. Aie ! Alors que si je fais bien mes tests, je prendrais en compte ce cas, et je pourrais le traiter avant de rencontrer ce bug...

Idéalement, il est même préférable d'écrire ses tests avant le code lui-même. Cela s'appelle le TDD, ou Test Driven Development (Développement piloté par les tests en français). Mais là, on dépasse largement le sujet, mais renseigne toi là dessus, c'est très intéressant !

[vinou92340]

Merci mais je ne comprends pas trop ton test sur la méthode de division. Globalement, quand je lance les tests via maven, où est ce que celui ci va aller chercher la liste des paramètres qui seront divisés ? Si je les entre moi meme, le test ne sert à rien non ? Ou est ce à moi de mettre la valeur 0, de vérifier que tout passe et de laisser le test dans un coin pour le refaire plus tard après 250 motifs dans le code ? Et techniquement, le code du test ne diffère t il donc pas de celui du code ?

Un autre point m'intrigue: L arborescence du projet que tu as mise. En effet le pom père vient d'un PROJET de packaging "pom" ? La partie et la partie java sont respectivement des modules enfants de packaging "war" et "jar" non ?

Merci d'avance pour ta reponse.

[romaintaz]

Merci mais je ne comprends pas trop ton test sur la méthode de division. Globalement, quand je lance les tests via maven, où est ce que celui ci va aller chercher la liste des paramètres qui seront divisés ? Si je les entre moi meme, le test ne sert à rien non ? Ou est ce à moi de mettre la valeur 0, de vérifier que tout passe et de laisser le test dans un coin pour le refaire plus tard après 250 motifs dans le code ?

Pourquoi le test ne servirait-il à rien ? C'est sûr que l'exemple que j'ai montré n'a pas grand intérêt, la méthode de division étant particulièrement isolée. Le but d'un test unitaire est double (en fait de tout type de test, qu'il soit unitaire ou non) :

• S'assurer qu'une méthode fait bien ce que l'on attend d'elle. On peut même considérer que le test est une sorte de "spécification" du code, dans le sens où il explique ce que la méthode doit faire.
• S'assurer qu'il n'y a pas de régression. Parfois, on écrit un code qui va indirectement changer le comportement d'un autre bout de code écrit auparavant. Si tu avais écrit des tests sur cet autre bout de code, ceux-ci vont désormais échouer (si tu mets en place l'intégration continue, tous tes tests sont exécutés très souvent), et tu sauras qu'il y a un problème avec ton code...

Idéalement, à chaque fois que tu écrits du code, tu dois aussi écrire des tests. Comme ça, tu auras des tests sur toute une partie de ton application, qui assureront ainsi à tout moment que le code fait bien ce qu'il doit faire. Après, tu peux aussi faire des analyses de couverture de code (avec des outils comme Sonar - cf. ma signature -, Cobertura, JaCoCo, etc.) qui te permettent de dire quelle partie de ton code est testée, et quelle partie ne l'est pas.

Et techniquement, le code du test ne diffère t il donc pas de celui du code ?

Qu'entends-tu par là ? Ton code reste du code Java qui va appeler ton code de "production" (cela dit, les tests peuvent s'écrire dans d'autres langages, selon le type de test que tu souhaites écrire, mais c'est un autre sujet).

Un autre point m'intrigue: L arborescence du projet que tu as mise. En effet le pom père vient d'un PROJET de packaging "pom" ? La partie et la partie java sont respectivement des modules enfants de packaging "war" et "jar" non ?

Le projet parent n'est qu'en fait que l'agrégation des projets librairie et web. Il est de type pom car il n'a que le pom.xml comme livrable. En gros, dans ce pom, tu vas indiquer toutes les informations communes à tes modules, comme par exemple certaines dépendances, des informations sur ton projet (comme le lien vers SVN/Git/...), les profils, etc. Chaque module héritera de ce pom (ils définissent le projet parent comme <parent>).