Discussion :

[plm12]

mon projet est du type

pom.xml
+-------- module A (packaging JAR), pom.xml
+-------- module B (packaging JAR), pom.xml
+-------- .........

le module A a besoin de B pour compiler, .... comment d'écrire dans les pom.xml cette dépendance inter-module.

[DanielW33]

dans le module A tu met une dependency sur l'artifact cree par le module B

[plm12]

j'ai 14 modules pouvant avoir des dépendances entre-eux, la méthode de faire un mvn install sur chaque modules ne fonctionne pas pb références manquantes à la compilation, idem avec mvn compile sur le pom principale.
Au finale je souhaite avoir 14 jar pour les mettre dans le WEB-INF\lib

[Tarul]

Pour compléter la réponse de daniel voici un exemple

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
<dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.company</groupId>
            <artifactId>module2</artifactId>
            <version>1.0-SNAPSHOT</version>
            <scope>compile</scope>
            <type>jar</type>
        </dependency>
        <dependency>
            <groupId>org.apache.ant</groupId>
            <artifactId>ant</artifactId>
            <version>1.7.0</version>
            <scope>compile</scope>
        </dependency>
    </dependencies>

edit:
dans ton pom principal, tu as bien déclaré les modules enfant? et dans les modules enfants, tu as bien déclaré le module parent?

[plm12]

merci pour votre aide, oui j'ai bien indiqué les modules enfants dans le pom parent, et le parent dans les modules enfants, si je mets dans le module 1 la dependance du module 2, lors du mvn compile avec le pom principal le module 2 se compile est tombe en erreur car il y a une dependance sur le module 1 --> erreur cyclic

[INFO] The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='releaseroxyClient'}' and 'Vertex{label='release:Architecture'}' introduces to cycle in the graph release:Architecture --> releaseroxyClient --> release:Architecture

[Tarul]

merci pour votre aide, oui j'ai bien indiqué les modules enfants dans le pom parent, et le parent dans les modules enfants, si je mets dans le module 1 la dependance du module 2, lors du mvn compile avec le pom principal le module 2 se compile est tombe en erreur car il y a une dependance sur le module 1 --> erreur cyclic

[INFO] The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='releaseroxyClient'}' and 'Vertex{label='release:Architecture'}' introduces to cycle in the graph release:Architecture --> releaseroxyClient --> release:Architecture

Bizzare, j'ai moi même un projet avec cette architecture :

pom projet (pom)
---module1 (jar) dépend de module2
---module2 (jar)

Tu n'aurais pas déclaré de dependency dans le pom principal? Car j'ai eut cette erreur lorsque j'ai débuté avec maven.

[plm12]

j'ai supprimer les dépendances dans le pom principal, même erreur cyclic ...

le module A fait réference au module B et vis-versa.

[Tarul]

le module A fait réference au module B et vis-versa.

Voilà ton erreur.

Il faut supprimer le dependency du module B vers A.
Ton module B n'a pas besoin de connaîte le module A pour compiler.

[GLSpirit]

Bonjour,
j'ai un probléme similaire mais dans mon cas

---module1 (jar) dépend de module2
---module2 (jar) dépend de module1

Je précise que dans mon cas je ne peux qu'avoir une dépendance mutuelle entre ces modules ...

Cela provoque donc évidement un probléme de dépendence cyclique.

J'ai tenté d'utiliser la balise exclusion mais cela n'a rien donné...

Module 1 :

<dependencies>

<dependency>

<groupId>path</groupId>
<artifactId>module2</artifactId>
<version>1.0</version>
<exclusions>

<exclusion>

<groupId>path</groupId>
<artifactId>module1</artifactId>

</exclusion>

</exclusions>

</dependency>

Module2 :

<dependencies>

<dependency>

<groupId>path</groupId>
<artifactId>module1</artifactId>
<version>1.0</version>
<exclusions>

<exclusion>

<groupId>path</groupId>
<artifactId>module2</artifactId>

</exclusion>

</exclusions>

</dependency>

[Tomekaa]

Les dépendances circulaires, c'est toujours une fausse bonne idée et heureusement que Maven les interdit

Il faut découper autrement les modules, ou en rajouter un autre (ou plusieurs même au besoin), mais en tout cas un module A ne peut dépendre de B si B dépend de A, quoi qu'il arrive !

[GLSpirit]

Je ne vois pas pourquoi cela devrait-être systématiquement une fausse bonne idée.

Parfois, cela peut provenir d'une erreur de conception.
Dans mon cas, je dois faire avec l'existant et il est impossible de détacher les classes d'un module sans casser une grande partie de l'appli.
Les dépendances circulaires peuvent aussi permettre de faire interéagir plusieurs module entre eux.

Quoiqu'il en soit, je ne peux pas déplacer les classes concernée par cette dépendance (au risque de tout casser et de mettre x jour à tout réparer).
Pour une question de maintenabilité, il n'est pas envisageable de dupliquer les classes concernées.

Je suis donc coincé ?

[Tomekaa]

A ma connaissance pas moyen de bypasser cette bonne pratique en Maven 2, comment pourrait-il d'ailleurs dès lors induire un ordre de build ?

Je reste convaincu du gain de temps à log terme que dégagerait une réorganisation des modules pour éliminer ces inter-dépendances, mais ce n'est pas toujours facile de faire comprendre le coût de la dette technologique (Technical Debt) à sa hiérarchie

[GLSpirit]

Je reste convaincu du gain de temps à log terme que dégagerait une réorganisation des modules pour éliminer ces inter-dépendances, mais ce n'est pas toujours facile de faire comprendre le coût de la dette technologique (Technical Debt) à sa hiérarchie

Je suis malheureusement limité par le temps.
Cela reflète l'éternel problématique du rapport coût "immédiat" / coût sur le long terme + justification du temps passé et du gain de temps sur le long terme.

Je me suis souvent retrouvé dans des situations / projets dans lesquels passer un peu plus de temps permettait d'obtenir un gain de temps sur le long terme. Cela est parfois/souvent mal perçu par la hiérarchie. Il est aussi arrivé que les exigences d'un projet préfère un temps de dév. rapide et douteux quitte à se dire "le principale c'est que ça marche" ou "on retouchera ça plus tard si nécessaire" afin de donner un semblant d'impression de rentabilité (à court terme bien sur ).

Je suis passé à autre chose pour l'instant (plus prioritaire).

[bobuse]

C'est effectivement impossible d'avoir une dépendances cyclique à la compilation. Par contre, ça doit être possible d'avoir une dépendance module1->module2 pour le scope compile (par défaut) et une dépendance module2->module1 pour le scope runtime (exécution).
Si vraiment tu as besoin de dépendance cyclique à la compilation, il ne te reste plus qu'à fusionner tes deux modules en un seul !