Propagation des goals

Version imprimable

21/02/2011, 22h08
TiEuM

Propagation des goals

Bonjour,

Je débute sur maven, et même si je pense m'être débrouillé jusqu'ici, impossible de trouver une réponse à mon problème...
J'ai 3 projets maven 2 :

- monprojet-web : appli web (war)
- monprojet-cron : appli java standalone (jar) qui sera lancée en prod via crontab
- monprojet-common : librairie commune (jar)

monprojet-web et monprojet-cron déclarent tous les 2 monprojet-common comme dépendance (scope=compile).

monprojet-web et monprojet-cron ont des cycles de vie différents (je peux vouloir faire une release de l'un sans l'autre et vice-versa).

QUESTION : Imaginons je viens de faire une modification dans le code du projet monprojet-common et une autre dans monprojet-web. J'aimerais maintenant déployer une version du war qui prenne en compte ces modifications.
Comment faire pour que le "mvn package" que je vais exécuter dans monprojet-web soit automatiquement répercuté à monprojet-common, de manière à ce que je n'ai pas à l'exécuter 2 fois ?

PS : j'ai pensé à créer un projet multimodule englobant mes 3 projets mais ça n'irait pas car web et cron n'ont pas le meme cycle de vie ...

Merci bcp à celui qui m'apportera ses lumières :)
21/02/2011, 23h43
tchize_

Citation:

Envoyé par TiEuM

PS : j'ai pensé à créer un projet multimodule englobant mes 3 projets mais ça n'irait pas car web et cron n'ont pas le meme cycle de vie ...

Merci bcp à celui qui m'apportera ses lumières :)

Pourtant c'est la meilleur solution, et ce n'est pas contradictoire.

tu peux très bien avoir à un moment donné, pour les versions dans tes poms

-> parent = 1.0-SNAPSHOT
-> web = 1.5-SNAPSHOT (dépend de common 2.6-SNAPSHOT)
-> common = 2.6-SNAPSHOT
-> cron = 2.1.4 (dépend de common 2.4)

Bref, maven n'oblige pas à ce que tous les sous projet d'un multimodule aie le même numéro. Pire, vous pouvez même créer plusieurs multimodules englobant les meme modules.

La seule chose qui sera problématique, c'est que vous ne pourrez pas utiliser mvn release et release:prepare à partir du projet maitre. Mais ca, c'est du détail ;)
21/02/2011, 23h55
gboissinot

De mon point de vue, un projet multi modules n'est pas une bonne solution, voir la pire!!!
Si les projets ne suivent pas le même cycle de vie, ce ne devait pas être un projet multi modules car cela pose trop de problème, comme le fameux processus de release cité par @tchize_ --> Et ainsi c'est bloquant.
De plus, ce n'est pas maintenable sur le long terme.

@TiEuM
Dans ton cas, tu dois gérer ton projet common comme une librairie indépendante et déclarer sa dépendance dans les projets web et cron.
22/02/2011, 00h06
tchize_

y a pas de mal à se mettre un multimodule pour se simplifier la vie, c'est juste que ce multimodule est hors cycle de release (tu peux même te contenter de le créer, faire ton dev, puis le détruire). Le but est de simplifier les commandes quand tu modifie 2 ou trois projets interconnectés d'un coup.

+ le problème de release est facile à résoudre, suffit de faire, comme dit, des release indépendantes:

cd common,
release
cd ../web
update pom.xml
release

:roll:

Les compilation, tests on en fait 50 / jour, les releases 1 toutes les semaines à tout casser, personellement, je sais tout suite où je préfère mettre la difficulté :mouarf:
23/02/2011, 18h44
TiEuM

Merci beaucoup pour vos réponses !

@Tchize : je ne suis pas sur de comprendre en quoi les versions snapshots différentes répondent à la problématique de la propagation d'un "mvn package".

Quant à créer un projet parent pour compiler web et un autre pour compiler cron ça me semble un peu trop commplexe ...

@gboissinot : pareil, on est d'accord que si je déclare common en tant que librairie indépendante dans les cron et web, je ne pourrai pas propager à common un "mvn package" exécuté dans web par exemple ?

Ou alors y a-t-il quelquechose à côté duquel je passe ?

Citation:

Envoyé par TiEuM

Merci beaucoup pour vos réponses !

@Tchize : je ne suis pas sur de comprendre en quoi les versions snapshots différentes répondent à la problématique de la propagation d'un "mvn package".

Il n'y répondent pas, ce que je dit depuis le début, c'est que justement le problème que vous amenez n'en est pas un, vous créez un parent et les enfants ont le propre version, c'est tout.

Quand à créer des parent différencier, ça prend 15 lignes. Si on imagine cett structure
Code:

1 2 3 4 5 6 7 8 9 10 common/ web/ standalone/ on peux faire common/ web/ /multi pom.xml standalone/
et le pom.xml:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.company.project</groupId> <artifactId>web-multimodule</artifactId> <version>1.0-SNAPSHOT</version> <packaging>pom</packaging> <modules> <module>../web</module> <module>../../common</module> </modules> </project>