Discussion :

[Frederik]

Bonjour à toutes Zé à tous...

J'ai écrit un pom qui compile correctement grâce au plug in "maven-compiler-plugin".

J'obtiens un beau *.jar à la fin.

Mais ce que je voudrais ce serait deux archives *.jar. La première qui rassemble toute une série de classes abstraites (et d'interfaces) et une autre qui recense les classes implémentées.

c'est à dire : /src/main/java/pipo/molo contient les classes abstraites

et /src/main/java/pipo/molo/impl comporte les implémentations.

Au moyen de maven-compiler-plugin (entre les balises <build></build>) j'ai essayé <excludes><excludes> mais je me fait insulté!!!

ce serait vraiment cool si quelqu'un avait une (bonne) idée sur la chose...

[marcxa44]

essaie de faire deux pom.xml différents pour construire deux jars.
Dans chacun des pom.xml tu exclu les fichiers que tu ne veux voir à l'intérieur.

[Frederik]

j'apprécirais grandement que tu m'indiques comment exclure certaines parties de l'arborescence, merci d'avance.

[denisC]

j'apprécirais grandement que tu m'indiques comment exclure certaines parties de l'arborescence, merci d'avance.

La théorie maven voudrait que tu en fasses deux projets indépendant, un contenant l'API et l'autre l'implémentation.

Bien entendu, le deuxième utilisera le premier....

[Frederik]

Ok...effectivement... c'est plutôt futé de faire deux projets...
Mais mon problème reste la façon de l'implémenter dans le POM.

Je ne sais pas comment exclure des répertoires src/main/java/......./autres_repertoires les répertoires src/main/java/......./autres_repertoires/impl/

C'est à dire que le premier projet doit générer une archive avec uniquement des classes abstraites et des interfaces, et le second doit juste générer une archive avec les implémentations des premières classes et interfaces

La commande <exclude> du plugin "maven-compiler-plugin" n'a pas été concluante.

[denisC]

Ok...effectivement... c'est plutôt futé de faire deux projets...
Mais mon problème reste la façon de l'implémenter dans le POM.

Faut faire deux POMs, tout simplement. Et deux arborescences, avec deux repertoires src/main/java contenant l'un les interfaces, l'autre l'implémentation.

Après, tu peux faire un troisième POM pour le parent.

Cf : http://java.developpez.com/faq/maven...projet#projet1

[Frederik]

Ok je vais tenté cette approche...

Sinon j'ai à peine commencé une autre façon de faire qui a l'air interressante.

Au moyen du plugin "maven-compiler-plugin" entre les balises <configuration> j'ai inséré une balises <excludes> <exclude> qui me permet d'exclure certains fichiers et d'autres balises <includes><include > qui me permettent comme leur nom l'indique de faire l'inverse.

De toute façon je ferai les deux solutions. Si quelqu'un a déjà tenté cette approche je suis preneur du rretour d'expérience.

PS: Je n'utilise pas maven brut de décoffrage, je passe par Maestro. On dirait que la balise <module> il est pas très fan d'ailleurs....

[denisC]

PS: Je n'utilise pas maven brut de décoffrage, je passe par Maestro. On dirait que la balise <module> il est pas très fan d'ailleurs....

Tu m'étonnes un peu avec cen genre de remarques... Mais on va bien voir si emmanuel est d'accord avec toi.

[Frederik]

Pareil que toi!!! moi aussi j'admets que j'ai un doute... mais je n'ai pas eu le temps de faire plusieurs tentatives....

Je ne pourrais faire ces tests que demain... Aujourd'hui je ne suis pas sur mon poste...

Sinon Merci pour vos conseils.

A vrai dire ce qui me dérange dans la solution que vous proposez tous (même si elle me parrait pas trop mal) c'est qu'il faut remanier toute la belle organisation des repositories SVN que j'ai mis derrière.

En effet, chaque fois que je lance un "build", un check out de la base svn est fait avant...

Et tout modifier maintenant pourquoi pas, mais ça me semble un peu lourd du côté SVN... Mais si il n'y a pas d'autres solutions alors pourquoi pas...

Donc l'idée c'est de se rapprocher au maximum de la "Solution idéale" en modifiant le moins possible la base SVN

Merci encore pour les infos...

[evenisse]

PS: Je n'utilise pas maven brut de décoffrage, je passe par Maestro. On dirait que la balise <module> il est pas très fan d'ailleurs....

Quelle est pour toi la différence entre maven et celui intégré dans Maestro?
La seule différence entre les deux est l'adresse du repository central.

La balise ,module. fonctionne TRES bien dans maven, il suffit de l'utiliser dans un pom.xml ayant le packaging définit à "pom". Un pom de type jar, war, ear... ne peux inclure des modules.

[evenisse]

Par définition, un projet maven ne doit créer qu'un et un seul artifact sauf cas exceptionnel comme le type ejb qui génère un ejb jar et un jar client.

Une application multi-artifact doit respecter cette architecture:

Code :

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

1
2
3
4
5
6
7
 
ROOT
   - pom.xml   =>packaging=pom
   - module1
       -pom.xml
   - module2
       -pom.xml

Avec cette séparation, la gestion des dépendances est correcte et surtout il n'ya aucun risque d'ajouter la mauvais classe dans le mauvais jar et de créer des liens entre classes non autorisés, par exemple entre une classe abstraite et une implémentation.

[Frederik]

Finalement vous aviez raison (comme c'est étonnant...).
Un module qui contient les API et un autre les implémentations celà semble très correct (en tout cas ça fonctionne).

J'ai essayé de ne faire qu'un seul fichier pom quand même (un peu SM sur coup là...) au moyen des <profiles> et des <excludes> et <includes>.

Bilan: celà devient vite indigeste. En plus le plug-in maven-installer-plugin lorsqu'il copie la première archive il la renomme du nom de l'artifactId avant de la placer dans le repository. (alors que dans le répertoire target il y avait un tout autre nom d'archive jar)

Si bien qu'il y a un problème lorsque la deuxième archive doit etre traitée. Elle écrase la première et s'appelle elle même...

Je ne sais pas si j'ai été claire mais grosso modo... la solution du découpage en module fonctionne


Merci à tous