Maven pour la mise en production

Bonjour,
je suis dans une équipe qui maintient une application Web , principalement en Java (un peu de PL/SQL aussi) de 10 Web-App (env 5000 classes/400 écrans).
Nous avons un socle "commun" qui sert à toutes les web-app (utilitaires, classes de persistance) et bien sûr tout un paquet de Jar externes (type log4j,...)
L'application est en évolution permanente : nous livrons des correctifs/évolutions environ une fois par mois : nous livrons des fichiers (ceux qui ont été modifiés), et non pas des jar/war/ear,...
Notre gros problème est que la préparation d'une livraison est chronophage et risquée : un fichier oublié et BOUM !
Notre objectif et de mettre en place un gestionnaire de version type SVN mais aussi un outil comme Maven pour automatiser la livraison, les tests,...
Il nous est difficile de livrer des versions complètes à chaque fois (cad toutes las classes) en raison du volume.
Comment organiser notre application en projets Maven afin d'assurer correctement les livraisons ? Ou bien faut-il un autre outil ?

Merci pour vos réactions...

Hum, vaste sujet !
En gros, vous voulez faire du versionning de vos livrables et de l'integration continue.
Cela implique de mettre en place 3 choses, dont certaines existent peut-etre deja :
* Un serveur de sources : subversion ou cvs
* Un proxy/repository maven : proximity ou nexus par exemple
* Un serveur d'integration continue : Continuum, Cruise Control, Hudson ...

Cet article en parle :
http://martinfowler.com/articles/con...tegration.html
et sur developpez :
http://loic-mathieu.developpez.com/c...ruise-control/

Ensuite chaque projet devra avoir une arborescence maven et un pom, je t'iinvite donc à regarder la faq maven de developpez ou d'aller sur le site officiel de maven.

pour ce qui est de livrer les librairies, vous pouvez:

utiliser maven pour faire un "release" chaque mois de toutes vos librairies internes
faire un package de chaque webapp, ou tout du moins un dependency:copy-dependencies pour envoyer toutes les libraires vers un dossier svn.

Faire un diff sur ce dossier pour avoir la liste des jar mise à jour.


Exemple:
pendant le mois de développement, l'équipe met à jour lib1, lib2 et lib3 vers les versions respective 12.5, 8.4 et 2.6.2. En même temps, sur la webapp X, il décident de passer de lib1 version 10.1 à lib1 version 12.5. Fin de mois, l'opération suivante sera faite

copier toutes les dépendances de webapp X vers "svn/binaries/clientMachin/webappX", on verra lors de ce commit que le seul changement est le passage de lib1 de 10.1 à 12.5. Ensuite, pour envoyer au client, il suffira de faire une liste des fichiers modifié (svn le permet) et dans un script récolter ces fichier pour en faire un archive à envoyer au client.

Maven n'interviendrait que pour la gestion automatique des dépendances. Via le dependencies-copy, on récupère toutes ces dépendances et on peut commencer à constituer les patch client, hors maven.

Difficile de réaliser facilement cela. Le souci étant que chaque release aura sa propre liste de fichiers mis à jour...

Déjà, il faudrait de maveniser le tout, de façon traditionnelle. Comme ça, tu utilises le packaging normal pour créer tes WAR et autres JAR.

Si tu ne souhaites livrer qu'un sous ensemble de fichiers pour ton WAR, (c'est-à-dire faire un patch), tu pourrais éventuellement t'orienter vers assembly, qui te permettrait de créer un ZIP à décompresser dans un WAR déjà installé. Le souci de cette solution c'est de créer le fichier assembly.xml qui liste les fichiers à inclure dans le patch... Là aussi, un oubli pourrait être fatal. Et puis ça t'oblige à avoir un assembly par release.
Une autre idée serait de "nourrir" le fichier assembly.xml par le biais du plugin changelog, qui peut lister les fichiers modifiés sur le SCM (c'est-à-dire le gestionnaire de sources de type CVS, SVN, etc.) depuis une certaine date (à savoir la date du dernier patch).

Je ne sais pas si je suis bien clair, mais ce qui est sûr, c'est qu'il n'y a pas (à ma connaissance) de solution déjà toute faite pour ce type de problème...