Maven & Eclipse : Multiple répertoire sources et destinations

Bonjour,

je souhaiterai avoir un projet avec de multiple répertoire sources et destination
src/main/java --> target/main/classes
src/public/java --> target/public/classes
src/mock/java --> target/mock/classes

J'ai conscience que ca n'est pas standard mais a priori je ne peux pas faire autrement pour des raisons variées.

J'ai vu que le plugin Build Helper pouvait rajouter plusieus répertoire sources mais maintenant se pose la question d'avoir plusieurs répertoires cibles

Et pour couronner le tout j'aimerai avoir une intégration Eclipse.

Quelqu'un aurait-il des pistes?

Concernant les répertoires de sources, cela se modifie facilement et le besoin est souvent justifié.
En revanche, concernant les répertoires de destination, c'est plus difficile à modifier avec Maven, qui n'a pas été conçu initialement pour cela.

Cela dépend de comment c'est exploiter ensuite.

Je me permet quand même de te poser la question: Est-ce obligatoire dans ta situation d'utiliser Maven? Si tu as la choix, switcher sur un autre système de build offrant plus de flexibilité pourrait être préférable.

Citation:

---

Envoyé par gboissinot

Concernant les répertoires de sources, cela se modifie facilement et le besoin est souvent justifié.
En revanche, concernant les répertoires de destination, c'est plus difficile à modifier avec Maven, qui n'a pas été conçu initialement pour cela.

Cela dépend de comment c'est exploiter ensuite.

Je me permet quand même de te poser la question: Est-ce obligatoire dans ta situation d'utiliser Maven? Si tu as la choix, switcher sur un autre système de build offrant plus de flexibilité pourrait être préférable.

---

Je suis en clientèle avec un certain nombre de contrainte technique et organisationnelle. Et de fait je dois les respecter.
En fait l'idée c'est d'avoir un répertoire src/main/java pour l'implémentation des EJB et un src/public/java pour les interface remote et les DTO.

si les contrainte du client sont absurbes ou inflexibles (peut-être pour de bonnes raisons mais très peu probable), ce sera impossible d'utiliser maven, un peu de bon sens.

On pourrais avoir vaguement la structure voulue avec quelque chose comme

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

parent/ pom.xml src/ main/ java/ pom.xml (target = ../../target/main) public/ java/ pom.xml (target = ../../target/public) mock/ java/ pom.xml (target = ../../target/mock)

---

Mais franchement ce serait tordu et ça ne résoudrais pas deux questions:
que faire des compilation des tests, de l'instrumentation, des résultats des tests, des artefacts intermédiaires, .... ?

Sans compter que si ton client te fait ch** avec un structure de fichier pareille, il y a fort à parier qu'il t'enverra péter aussi pour
-> le repository d'entreprise
-> les numérotations des version
-> les noms des artefacts générés
-> ....

Avec un client pareil ant est la voie de la sagesse, on fait tout à la main, on perd toutes les gestions des dépendances et du cycle, mais au moins, on fait ce qu'on veux :aie:

Dans tous les cas, pour l'intégration eclipse, tu peux te brosser. Eclipse a un seul répertoire cible par projet (par défaut, bin/).

Citation:

---

Envoyé par tchize_

si les contrainte du client sont absurbes ou inflexibles (peut-être pour de bonnes raisons mais très peu probable), ce sera impossible d'utiliser maven, un peu de bon sens.

On pourrais avoir vaguement la structure voulue avec quelque chose comme

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

parent/ pom.xml src/ main/ java/ pom.xml (target = ../../target/main) public/ java/ pom.xml (target = ../../target/public) mock/ java/ pom.xml (target = ../../target/mock)

---

Mais franchement ce serait tordu et ça ne résoudrais pas deux questions:
que faire des compilation des tests, de l'instrumentation, des résultats des tests, des artefacts intermédiaires, .... ?

Sans compter que si ton client te fait ch** avec un structure de fichier pareille, il y a fort à parier qu'il t'enverra péter aussi pour
-> le repository d'entreprise
-> les numérotations des version
-> les noms des artefacts générés
-> ....

Avec un client pareil ant est la voie de la sagesse, on fait tout à la main, on perd toutes les gestions des dépendances et du cycle, mais au moins, on fait ce qu'on veux :aie:

Dans tous les cas, pour l'intégration eclipse, tu peux te brosser. Eclipse a un seul répertoire cible par projet (par défaut, bin/).

---

Non mon client me demande de faire un état des lieux et d'expliquer par A+B les changements. Comme ce n'est pas standard et que je veux revenir au standard, je vérifie tout de même si il n'y a pas de moyen simple de faire plaisir à tout le monde. Mais j'ai la confirmation de ce que je pensais. Merci

Dans ce cas là, si tu veux amener maven pour ses avantages, le mieux est de recommander à ton client de suivre les conventions maven de base. Pourquoi?

1) c'est recommandé par les auteurs même de maven
2) un jour, tu amènera peut être sur un projet un plugin maven qui se base sur le respect ces conventions et refuse de fonctionner quand on s'en éloigne de trop
3) ça permettra au développeur de gérer facilement les sources tierces si un jour un patch doit être fait à une librairies open source et / ou on doit en explorer le code
4) ça va faciliter fortement la configuration et le maintient des serveurs d'intégration continue si tu en utilise un.
5) ça simplifie l'écriture, et donc la lecture et la compréhension des fichiers maven, donc une maintenabilité facilitée
6) l'intégration dans des ide ne supporte pas toujours toutes les configuration exotique, encore une fois, ça facilitera le travail des programmeurs.
7) ça limitera les formation futures des nouveaux développeurs
7 bis) toutes les docs et exemples relatifs à des problèmes qu'ils auront seront plus claires si les chemins sont les mêmes ;)

maintenant, on ne traite pas non plus de la même manière nouveau et ancien projet. Il faut parfois sacrifier aux standard pour arriver à maintenir une double compilation un certain temps sur les ancien projets. Ainsi, j'ai quelque projets ici qui ont été convertis de ant -> maven. On a mis plus d'un an à coup de refactoring progressifs pour en faire des projets maven +- standards :)