Déploiement JEE depuis Archiva

[cocoyot]

Je développe une application JEE, mon EAR est déployé sur un repository d'entreprise Archiva.
Y a-t-il une solution simple, une seule commande mvn, pour récupérer la dernière version de l'EAR pour le déployer sur mon serveur d'application ?
Ou la seule solution est-elle de connaître l'URL de l'EAR sur Archiva et de faire un wget ?
Merci d'avance

[romaintaz]

Hello,

Quel est ton serveur d'application ?

Tu peux déjà jeter un oeil sur le plugin cargo, qui permet ce genre de déploiement.

[cocoyot]

Mon serveur c'est JBoss, j'utilise déjà cargo pour le déploiement en local sur mon poste de développement. Au passage, je n'ai pas trouvé de solution pour faire un upload sur un serveur distant (?).

Mais je crois que ma question est mal posée. En fait, sur une machine où j'ai uniquement maven d'installé (avec un settings.xml ad-hoc), sans aucun pom.xml, est il possible de déployer avec maven en récupérant l'EAR et le pom depuis Archiva ?

[aheritier]

Pour faire ce genre d'operations sur une machine tierce, je ne pense pas que Maven soit le meilleur outil. Je te conseillerai plutot de faire du ant ou groovy en utilisant si necessaire les taches ant de cargo et maven.
Cargo permet de faire du deploiement remote a condition que l'implémentation du serveur d'app le supporte. La configuration par contre n'est pas toujours aisée.

[cocoyot]

Décidément, je trouve que les solutions sont bien complexes pour des problèmes tellement simple !
En choisissant Maven, je pensais pouvoir :
- compiler en développement : pas possible il faut intégrer eclipse ou netbeans, bon avec eclipse 3.4, ça se passe sans difficulté à présent mais quelque galère auparavant (projet JEE multi-modules) !
- déployer en local : ok, mais comme j'utilise eclipse, il le fait aussi.
- déployer en distant : pas possible simplement
Le seul intérêt que j'y vois c'est d'avoir une description des dépendances des projets.

Merci beaucoup d'avoir pris le temps de me répondre

[aheritier]

Je ne vois pas les mêmes intérêts a maven :
- compilation : je ne veux pas passer mon temps entre la ligne de commande et mon IDE sinon je perds l'interet de l'IDE. Maven et l'IDE doivent donc le faire de la même manière et ce en toute transparence. Le probleme c'est que des IDEs comme eclipse sont a la traine par rapports aux fonctionnalités apportées par Maven. m2eclipse en lève certaines mais c'est pas encore parfait.
- deploiement local : Dans le cadre d'eclipse c'est WTP, point barre. Je veux pouvoir debugger, faire du pas a pas etc... Seul cas ou maven doit le le faire en local : Tests d'intégration automatisés (selenium & co)
- deploiement distant : Maven sait le faire mais si il est lancé dans le build du projet en question. Le but est de la faire par exemple dans la boucle d'intégration continue pour mettre a disposition automatiquement l'application sur une plate-forme de tests.
- Les dépendances : C'est déjà pas mal car ça manquait vraiment.

Maven n'est pas magique.
http://sites.google.com/site/nantesj...ontres-passees
Dans ma dernière prez tu peux trouver 10 moyens de planter ton projet avec Maven ;-)

[cocoyot]

Ok, on a pas la même façon de voir les choses. Moi, je ne suis pas spécialiste d'intégration et de build, je suis juste ingénieur sur un projet JEE, et j'avais besoin d'un outil indépendant de tout IDE pour le build et le déploiement. Et ce qui m'a aussi séduit c'est la possibilité d'intégrer ou non des modules dans un EAR : je n'ai pas trouvé de solution qui fonctionne (cf ce post).

Ensuite pour ce qui est du déploiement, à distance, je n'ai pas trouvé la réponse à comment uploader un EAR sur JBoss ...

Donc pour moi ça a été beaucoup de temps passé pour un bénéfice réel mais je m'attendais à mieux. Et je suis d'accord le fait de gérer les dépendances c'est bien, j'aurais dû m'en tenir à cela ... J'en demande trop certainement

[rseM2]

Bonjour,

Envoyé par cocoyot

Ok, on a pas la même façon de voir les choses. Moi, je ne suis pas spécialiste d'intégration et de build, je suis juste ingénieur sur un projet JEE, et j'avais besoin d'un outil indépendant de tout IDE pour le build et le déploiement.

Une bonne pratique est la reproductibilité dans le temps et dans l'espace.
Généralement, l'outil de build permet de gérer l'automatisation du build et doit adresser cette bonne pratique. Un serveur d'intégration continue va aider notamment sur l'aspect reproductibilité dans l'espace. C'est la machine d'intégration continue qui est la référence. Cela permet d'éviter le "ca marche chez moi !". Oui mais pour cela tu as ajouter une dépendance dans ton eclipse et donc ce n'est pas bon car pas reproductible...

Envoyé par cocoyot

Et ce qui m'a aussi séduit c'est la possibilité d'intégrer ou non des modules dans un EAR : je n'ai pas trouvé de solution qui fonctionne (cf ce post).

Je viens de regarder rapidement. Difficile à dire d'où vient le problème. Mais maven n'est pas parfait et il se peut que ce soit un bug. Dans ce cas, la meilleure chose est de le remonter en ouvrant une issue. C'est comme cela qu'on essaye de faire avancer la communauté open-source.

Envoyé par cocoyot

Ensuite pour ce qui est du déploiement, à distance, je n'ai pas trouvé la réponse à comment uploader un EAR sur JBoss ...

Généralement on utilse cargo. Comme te l'a précisé Arnaud, il faut que l'implantation concerné (ici JBoss) est implanté cette fonctionnalité. Pour la version 4.2.x à priori c'est bon. Si ce n'est pas le cas, le mieux est de contacter/financer les auteurs. C'est ce que nous avons fait pour JOnAS par exemple pour qu'il soit aussi dans cargo.

Envoyé par cocoyot

Donc pour moi ça a été beaucoup de temps passé pour un bénéfice réel mais je m'attendais à mieux. Et je suis d'accord le fait de gérer les dépendances c'est bien, j'aurais dû m'en tenir à cela ... J'en demande trop certainement

Il se peut que maven ne réponde pas à tes attentes. Maven a encore des lacunes.
Mais comme pour n'importe quel outil, l'important est toujours de voir la balance les points positifs et négatifs et d'essayer avec ses moyens de faire avances les différentes communautés.

Rémy