Re: Partager un modèle jpa entre plusieurs wa r

Si c'est çà, je préfère gérer plus finement mon processus de livraison et mes tags SVN plutôt qu'un tel impact sur le packaging de l'appli.

... et si vraiment, c'est impossible de synchroniser cette grosse équipe de plus de 100 développeurs, alors, il me semble préférable de structurer mon code plutôt qu'avoir un impact @runtime.
Par exemple, avec des repository de jar pour ne pas toujours tout relivrer, mais à la fin, tout cela est packagé dans le même livrable pour un seul runtime, une seule application.
Du coup, il faudrait mettre en place Maven, mais alors seulement si la taille de l'équipe le justifie ... car mettre en place Maven, c'est pas rien !

Sinon, la plus part du temps, synchroniser l'équipe de dev au moment de la livraison afin de ne pas sauvagement livrer la HEAD, me paraît plus simple.

On 27 juil. 2011, at 10:26, Sebastien Cesbron wrote:

> L'idée derrière c'est d'être le plus fin au niveau de la mise en prod pour être sûr de ne pas impacter un composant auquel on n'a pas touché (par exemple pris en compte d'une modification sur ce composant en cours de dev alors qu'on ne voulait pas le faire).
> 
> a+
> seb
> 
> Le 27 juillet 2011 09:58, Jean-Baptiste BRIAUD -- Novlog <[email protected]> a écrit :
> Réponse un peu tardive, mais Idem pour moi.
> Je pense qu'un tel découpage est très risqué et va apporter son lot de problèmes.
> 
> De plus, je ne comprends pas bien le problème que cette solution est censé résoudre ?
> De fait, à chaque livraison, il faut redéployer toute l'application ... et alors ?
> 
> 
> On 27 juil. 2011, at 09:24, Patrice Godard wrote:
> 
>> Bonjour,
>> J'ai aussi tendance à être de cet avis.
>> Je suis actuellement spectateur d'un tel début de "war nightmare"....et d'enfer de gestion de conf.
>> Sans parler de l'EAR final qui frole déjà les 150MO et qui va encore grossir... (va falloir penser à mutualiser des dépendances!...)
>> 
>> Même il peut être intéressant de scinder une grosse appli en .war multiples tout de même. Reste à déterminer le niveau de granularité.
>> 
>> J'aime assez l'idée de déployer dans un conteneur OSGi qui permet une réutilisation facile des différents modules (mais on se heurte aussi à une gestion de versions qui peut vite devenir casse-tête je présume).
>> 
>> My 2 cents,
>> Patrice
>> > Message du 27/07/11 09:08
>> > De : "Cédric Beust ♔" 
>> > A : "Sebastien Cesbron" 
>> > Copie à : "java" 
>> > Objet : Re: Partager un modèle jpa entre plusieurs war
>> >
>> > Mon expérience, c'est que ce genre de modèle (wars multiples) tourne très rapidement au cauchemar. Tu abandonnes toute la sécurité du typage statique et tu entres dans le domaine de l'enfer des versions. Déploie deux wars incompatibles, tu récupères des tonnes d'erreurs au déploiement. Les rollbacks sont également considérablement plus difficiles à effectuer.
>> 
>> >
>> Rien ne t'empêche d'organiser tes fichiers en modules, mais quand tu en viens à la création de l'artefact, crée un seul war/jar. Ce modèle a aussi des tas d'avantages d'un point de vue collaboration en équipe, mais je ne vais pas trop m'attarder là-dessus.
>> 
>> -- 
>> Cédric
>> > 
>> >
>> 
>> > 
>> > 
>> >
>> 2011/7/26 Sebastien Cesbron <[email protected]>
>> >
>> Salut la liste
>> > 
>> > En ce bel été fort peu ensoleillé, je me permets de soumettre quelques questions à la sagacité collective.
>> > 
>> > Je me remets à faire du dev après quelques années passées les mains dans l'infra et je me repose quelques questions existentielles car les personnes avec qui je travaille n'ont pas forcément la même approche que celle à laquelle j'étais habitué.
>> > 
>> > Pour ma part j'étais habitué à avoir pour un domaine fonctionnel donné une application se composant d'une base et d'une appli jee au dessus généralement sous la forme d'un war avec hibernate pour la partie mapping.
>> > 
>> > On me soumet l'idée que pour faciliter l'évolutivité des différents composants du domaine fonctionnel on pourrait splitter ce war unique en n war qui chacun contiennent la définition du modèle (partagé sous forme d'un module maven) et d'un service donné. Cela permet de faire évoluer les services indépendamment les uns des autres tant que le modèle est stable.
>> > 
>> > Que pensez vous de cette solution ? Quels inconvénients y voyez vous ? L'avez vous déjà mise en oeuvre et si oui quels problèmes avez vous rencontrés ?
>> > 
>> > Pour ma part je vois deux problèmes potentiels mais non rhédibitoires :
>> >
>> consommation mémoire légèrement supérieure car on instancie n fois la glue hibernate / spring
>> pas de possibilité d'utilisation du cache de second niveau d'hibernate sinon on peut avoir des pbs de désynchronisation entre le cache et le base
>> Voilà si certains ont un avis je suis preneur
>> > 
>> > A+
>> > Seb
>> >
>> 
>> 
>> >
>> 
>> 
>> 
>> 
> 
>