débat: L'ajout de bibliothèques tierces à une guerre est-il une bonne idée?

Nous avons un débat en cours.débat: L'ajout de bibliothèques tierces à une guerre est-il une bonne idée?

a. La manière "standard" d'assembler une application web. Créez un WAR avec tous nos artefacts d'application et tous les autres composants comme hibernate et memcached etc sont déployés dans la zone tomcat/shared/lib.

b. Créer une guerre gigantesque avec tout inclus et rien dans tomcat/shared/lib.

Avantages pour a - Il garde les choses modulaires et la guerre est petite. Contre pour une - dépendance sur shared/lib doit être géré en particulier par le processus de déploiement.

Avantages pour b - Toutes les dépendances sont contrôlées par le processus de construction en supprimant toute possibilité d'erreur. Contre pour b - La guerre est vraiment, vraiment grande. Si vous effectuez un déploiement sur un réseau dans une immense batterie de serveurs, cela peut avoir un impact.

voulez voir quelles pensées les autres pourraient avoir à ce sujet.

Source

2010-06-17 Master Chief

En fait, je pensais que B était le chemin "standard" :-)

Je choisis B presque tout le temps. Il est plus simple pour nos clients - dont beaucoup n'ont pas les compétences d'administrer les serveurs d'applications Java - ils envoient simplement le fichier WAR à l'endroit où je leur dis et tout fonctionne. Il fonctionne également bien avec notre build et déploiement - le WAR est construit en utilisant maven, donc toutes les dépendances nécessaires sont incluses, et peuvent également être déployées sur nos serveurs d'application QA en utilisant le plugin cargo.

Il évite également "WAR-hell" lorsque vous avez plusieurs webapps nécessitant un hibernation ou une autre dépendance, mais des versions différentes.

Je choisirais A uniquement lorsque j'aurais un contrôle total sur le serveur d'application, et que la duplication des bibliothèques communes par webapp serait trop importante, ou que je pourrais faire en sorte que toutes les applications soient testées avec la même version des dépendances. Ensuite, je sais que les dépendances peuvent être déplacées en toute sécurité dans la zone partagée du serveur d'applications.

Source

2010-06-17 17:19:46 mdma

Intéressant. nous sommes en contrôle total du serveur. Vous faites des bons points, mais qu'en est-il de vouloir éviter d'avoir plusieurs versions du même composant dans des applications web différentes. Est-ce que ce n'est pas un objectif souhaitable du point de vue des ops/mgmt? Je trouve régulièrement plusieurs versions de parseurs XML, etc., sans autre raison que de ne pas être découragé. –

Je suis d'accord avec vous: si vous contrôlez les applications et le serveur, essayez de faire converger les versions des bibliothèques tierces. J'utilise maven, ce qui aide beaucoup avec ça. Même ainsi, je le vois comme un problème de gestion de version plutôt qu'un problème de déploiement. Le fait que toutes les applications aient été testées avec la même version d'une lib signifie que la bibliothèque peut être partagée, mais la gestion des versions doit venir en premier pour ouvrir la voie aux bibliothèques partagées. – mdma

Oui, je suis d'accord. Nous utilisons Maven pour gérer cela. Mais on envisage de passer à une guerre unique et on se demande s'il vaut la peine de changer et s'il y a des avantages que d'autres ont pu voir. –

débat: L'ajout de bibliothèques tierces à une guerre est-il une bonne idée?

Répondre

Questions connexes