Partager un modèle jpa entre plusieurs war

[Sebastien Cesbron]

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

[Hervé Agnoux]

Post by Sebastien Cesbron
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.

Si on part de l'hypothèse que le modèle est stable, quelle est la difficulté à
résoudre ?

[Cédric Beust ♔]

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

Post by Sebastien Cesbron
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 ?
- 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

[Patrice Godard]

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
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 ?
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

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

[Sebastien Cesbron]

Salut et merci pour les réponses

Au niveau du découpage, ce que je vois là où je suis c'est qu'il y a
plusieurs domaines fonctionnels et dans chaque domaine on a plusieurs
modules

actuellement on a un war par module et comme vous le dites tous j'ai peur
d'avoir des problÚmes de versionning en prod

par contre au niveau des grands modules fonctionnels, ça me parait pas mal
d'avoir des wars indépendants car ils ont un peu chacun leur vie propre.
AprÚs ces modules dialoguent entre eux par appel de service, c'est vrai
qu'on perd un peu au niveau du typage mais on découple donc l'un dans
l'autre ça évite d'aller dans l'autre sens à avoir une application énorme
qui régresse d'un bout à chaque fois que l'on met en prod un autre bout

seb

Post by Patrice Godard
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
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 ?
- 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

<https://compte.laposte.net/inscription/index.do?jeux=2011FOOTER_generique>

[Jean-Baptiste BRIAUD -- Novlog]

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 ?

Post by Patrice Godard
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
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 ?

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

[Sebastien Cesbron]

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 <

Post by Jean-Baptiste BRIAUD -- Novlog
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 ?
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
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 ?
- 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

<https://compte.laposte.net/inscription/index.do?jeux=2011FOOTER_generique>

[Jean-Baptiste BRIAUD -- Novlog]

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.

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
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 ?

Post by Patrice Godard
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
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 ?

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

[Baptiste MATHUS]

Oups, j'avais répondu en privé involontairement.

Ok si tomcat t'est obligatoire. Ok.

Pr ce que tu dis: c ça, c pas plus lourd que sens EJB. Ce que ça apporte ?
Au ms démarcation tx, sécurité par défaut sans rien à faire.

Et vu que tes besoins sont notamment sur la modularité, ça pouvait bien
correspondre.

-- Baptiste

Non c'est du tomcat/spring.
perso j'ai mis en prod des applis sous weblo avec appel ejb3 entre les
parties ihm et j'ai pas été convaincu par la techno. C'est pas que c'est
lourd mais je ne trouve pas que ça apporte grand chose
seb

Salut,
Tu es ds un serveur JavaEE ou non ?
Parce que tu peux aussi faire des EJB de tes services et là tu as le même
typage ou que tu sois, la démarcation transactionnelle...
--
Baptiste

Post by Sebastien Cesbron
Salut et merci pour les réponses
Au niveau du découpage, ce que je vois là où je suis c'est qu'il y a

plusieurs domaines fonctionnels et dans chaque domaine on a plusieurs
modules

Post by Sebastien Cesbron
actuellement on a un war par module et comme vous le dites tous j'ai

peur

d'avoir des problÚmes de versionning en prod

Post by Sebastien Cesbron
par contre au niveau des grands modules fonctionnels, ça me parait pas

mal d'avoir des wars indépendants car ils ont un peu chacun leur vie

propre.

AprÚs ces modules dialoguent entre eux par appel de service, c'est vrai
qu'on perd un peu au niveau du typage mais on découple donc l'un dans
l'autre ça évite d'aller dans l'autre sens à avoir une application énorme
qui régresse d'un bout à chaque fois que l'on met en prod un autre bout

Post by Sebastien Cesbron
seb

Post by Patrice Godard
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.

Post by Sebastien Cesbron

Post by Patrice Godard
Sans parler de l'EAR final qui frole déjà les 150MO et qui va encore

grossir... (va falloir penser à mutualiser des dépendances!...)

Post by Sebastien Cesbron

Post by Patrice Godard
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é.

Post by Sebastien Cesbron

Post by Patrice Godard
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).

Post by Sebastien Cesbron

Post by Patrice Godard
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.

Post by Sebastien Cesbron

Post by Patrice Godard

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.

Post by Sebastien Cesbron

Post by Patrice Godard

--
Cédric

Salut la liste

En ce bel été fort peu ensoleillé, je me permets de soumettre

quelques questions à la sagacité collective.

Post by Sebastien Cesbron

Post by Patrice Godard

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é.

Post by Sebastien Cesbron

Post by Patrice Godard

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.

Post by Sebastien Cesbron

Post by Patrice Godard

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.

Post by Sebastien Cesbron

Post by Patrice Godard

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 ?

Post by Sebastien Cesbron

Post by Patrice Godard

Pour ma part je vois deux problÚmes potentiels mais non

consommation mémoire légÚrement supérieure car on instancie n fois

la

glue hibernate / spring

Post by Sebastien Cesbron

Post by Patrice Godard

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

Post by Sebastien Cesbron

Post by Patrice Godard

Voilà si certains ont un avis je suis preneur

A+
Seb

[Sebastien Cesbron]

Oui les ejbs amÚnent la démarcation tx mais là on la fait avec Spring donc
c'est équivalent

Sinon une autre question connexe par rapport à ce que disait Cedric. Si je
pars sur n modules qui ensembles vont générer un seul artefact de type war :
ce genre de configuration s'articule bien avec un environnement de dev comme
eclipse ? Le redéploiement pour tester une nouvelle version n'est pas trop
long ? On est obligé de passer par la génération d'un war maven ou bien on
est compatible wtp ?

A+
Seb

Post by Baptiste MATHUS
Oups, j'avais répondu en privé involontairement.
Ok si tomcat t'est obligatoire. Ok.
Pr ce que tu dis: c ça, c pas plus lourd que sens EJB. Ce que ça apporte ?
Au ms démarcation tx, sécurité par défaut sans rien à faire.
Et vu que tes besoins sont notamment sur la modularité, ça pouvait bien
correspondre.
-- Baptiste

Non c'est du tomcat/spring.
perso j'ai mis en prod des applis sous weblo avec appel ejb3 entre les
parties ihm et j'ai pas été convaincu par la techno. C'est pas que c'est
lourd mais je ne trouve pas que ça apporte grand chose
seb

Salut,
Tu es ds un serveur JavaEE ou non ?
Parce que tu peux aussi faire des EJB de tes services et là tu as le

même

typage ou que tu sois, la démarcation transactionnelle...
--
Baptiste

Post by Sebastien Cesbron
Salut et merci pour les réponses
Au niveau du découpage, ce que je vois là où je suis c'est qu'il y a

plusieurs domaines fonctionnels et dans chaque domaine on a plusieurs
modules

Post by Sebastien Cesbron
actuellement on a un war par module et comme vous le dites tous j'ai

peur

d'avoir des problÚmes de versionning en prod

Post by Sebastien Cesbron
par contre au niveau des grands modules fonctionnels, ça me parait pas

mal d'avoir des wars indépendants car ils ont un peu chacun leur vie

propre.

AprÚs ces modules dialoguent entre eux par appel de service, c'est vrai
qu'on perd un peu au niveau du typage mais on découple donc l'un dans
l'autre ça évite d'aller dans l'autre sens à avoir une application

énorme

qui régresse d'un bout à chaque fois que l'on met en prod un autre bout

Post by Sebastien Cesbron
seb

a

Post by Sebastien Cesbron

Post by Patrice Godard
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.

Post by Sebastien Cesbron

Post by Patrice Godard
Sans parler de l'EAR final qui frole déjà les 150MO et qui va encore

grossir... (va falloir penser à mutualiser des dépendances!...)

Post by Sebastien Cesbron

Post by Patrice Godard
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é.

Post by Sebastien Cesbron

Post by Patrice Godard
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).

Post by Sebastien Cesbron

Post by Patrice Godard
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.

Post by Sebastien Cesbron

Post by Patrice Godard

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.

Post by Sebastien Cesbron

Post by Patrice Godard

--
Cédric

Salut la liste

En ce bel été fort peu ensoleillé, je me permets de soumettre

quelques questions à la sagacité collective.

Post by Sebastien Cesbron

Post by Patrice Godard

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é.

Post by Sebastien Cesbron

Post by Patrice Godard

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.

Post by Sebastien Cesbron

Post by Patrice Godard

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.

Post by Sebastien Cesbron

Post by Patrice Godard

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 ?

Post by Sebastien Cesbron

Post by Patrice Godard

Pour ma part je vois deux problÚmes potentiels mais non

consommation mémoire légÚrement supérieure car on instancie n fois

la

glue hibernate / spring

Post by Sebastien Cesbron

Post by Patrice Godard

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

Post by Sebastien Cesbron

Post by Patrice Godard

Voilà si certains ont un avis je suis preneur

A+
Seb

[Baptiste MATHUS]

Post by Sebastien Cesbron
Oui les ejbs amÚnent la démarcation tx mais là on la fait avec Spring donc

c'est équivalent

À ma connaissance, intra-war, tout à fait. Inter-war c'est pas gagné. Ça
impliquerait d'avoir un ApplicationContext commun aux deux wars. Or,
partager des instances d'objet java entre wars d'un tomcat sans annuaire
jndi rw ça se complique.

Post by Sebastien Cesbron
Sinon une autre question connexe par rapport à ce que disait Cedric. Si je

pars sur n modules qui ensembles vont générer un seul artefact de type war :
ce genre de configuration s'articule bien avec un environnement de dev comme
eclipse ? Le redéploiement pour tester une nouvelle version n'est pas trop
long ? On est obligé de passer par la génération d'un war maven ou bien on
est compatible wtp ?

Si tu utilises Maven, deux solutions principales :
* M2eclipse + wtp. Utiliser les deux ensemble a longtemps été trÚs
compliqué. Heureusement, ça s'améliore à présent depuis plusieurs mois suite
à l'embauche de Fred Bricon par RedHat à plein temps pr bosser à
l'intégration des deux (m2e + wtp)
* sinon, en fonction de tes contraintes je te conseillerais de regarder du
cÎté de webby. Projet créé par sonatype censé être plus simple et léger que
wtp pr faire du dev web ds Eclipse. Pas testé personnellement.

-- Baptiste

[Jean-Baptiste BRIAUD -- Novlog]

En supposant l'existence d'environnement de DEV, TEST et PROD ...

Question peut-être un peu trop simple, mais pourquoi donc utiliser tout cet "attirail" en dev ?
Pourquoi ne pas laisser Eclipse tout builder, tout simplement, sans Maven ou autre, juste pour le "run du dev".
De fait, tout redeviendrais plus simple : on change du code, on clique sur "run" et on voit se qui se passe.

Ensuite, a partir du "run du test", on passe à l'artillerie lourde mais comme c'est automatique (à la Jenkins ou autre Teamcity), c'est moins grave.
Ca ne se configure qu'une seule fois sur une seule machine, le serveur de test.
De sorte qu'en production, tout à été testé avec les outils cibles type Maven et autre "bout de jar" qui composent une appli, voire même sur une architecture OSGI si la modularité est devenue un objectif plutôt u'un moyen.

Le problème, c'est qu'au bout d'un moment, on ne programme plus, on passe son temps précieux à configurer tout ce véritable bazar, et on s'étonnera, sûrement sincèrement, que les dev n'avancent pas aussi vite que prévu, qu'ils sont démotivés, ...

C'est qu'à force de faire de la config et ne plus coder, on va finir par .....

argggll ... conf.xml.properties m'a tuer ...

Oui les ejbs amènent la démarcation tx mais là on la fait avec Spring donc c'est équivalent

À ma connaissance, intra-war, tout à fait. Inter-war c'est pas gagné. Ça impliquerait d'avoir un ApplicationContext commun aux deux wars. Or, partager des instances d'objet java entre wars d'un tomcat sans annuaire jndi rw ça se complique.

Sinon une autre question connexe par rapport à ce que disait Cedric. Si je pars sur n modules qui ensembles vont générer un seul artefact de type war : ce genre de configuration s'articule bien avec un environnement de dev comme eclipse ? Le redéploiement pour tester une nouvelle version n'est pas trop long ? On est obligé de passer par la génération d'un war maven ou bien on est compatible wtp ?

* M2eclipse + wtp. Utiliser les deux ensemble a longtemps été très compliqué. Heureusement, ça s'améliore à présent depuis plusieurs mois suite à l'embauche de Fred Bricon par RedHat à plein temps pr bosser à l'intégration des deux (m2e + wtp)
* sinon, en fonction de tes contraintes je te conseillerais de regarder du côté de webby. Projet créé par sonatype censé être plus simple et léger que wtp pr faire du dev web ds Eclipse. Pas testé personnellement.
-- Baptiste

[Baptiste MATHUS]

Le 28 juil. 2011 13:00, "Jean-Baptiste BRIAUD -- Novlog" <

Post by Jean-Baptiste BRIAUD -- Novlog
En supposant l'existence d'environnement de DEV, TEST et PROD ...
Question peut-être un peu trop simple, mais pourquoi donc utiliser tout

cet "attirail" en dev ?

Post by Jean-Baptiste BRIAUD -- Novlog
Pourquoi ne pas laisser Eclipse tout builder, tout simplement, sans Maven

ou autre, juste pour le "run du dev".

Je dirais : parce qu'on veut pas, qu'on ne doit pas refaire les mêmes choses
à deux endroits.
Or déclarer par exemple tes dépendances, tes source folders, etc deux fois
(une fois ds l'ide, une fois ds ton descripteur de build quel qu'il soit)
est une hérésie.
On l'a vécu et cela nous a parfois conduit à avoir un war final contenant
des versions de lib différentes de celles du dev.

Post by Jean-Baptiste BRIAUD -- Novlog
De fait, tout redeviendrais plus simple : on change du code, on clique sur

"run" et on voit se qui se passe.

Cf. Ci-dessus : pr moi c'est plus compliqué, donc, pas plus simple.

Post by Jean-Baptiste BRIAUD -- Novlog
Ensuite, a partir du "run du test", on passe à l'artillerie lourde mais

comme c'est automatique (à la Jenkins ou autre Teamcity), c'est moins grave.

Post by Jean-Baptiste BRIAUD -- Novlog
Ca ne se configure qu'une seule fois sur une seule machine, le serveur de test.
De sorte qu'en production, tout à été testé avec les outils cibles type

Maven et autre "bout de jar" qui composent une appli, voire même sur une
architecture OSGI si la modularité est devenue un objectif plutÎt u'un
moyen.

Post by Jean-Baptiste BRIAUD -- Novlog
Le problÚme, c'est qu'au bout d'un moment, on ne programme plus, on passe

son temps précieux à configurer tout ce véritable bazar, et on s'étonnera,
sûrement sincÚrement, que les dev n'avancent pas aussi vite que prévu,
qu'ils sont démotivés, ...

Je suis un peu d'accord, ms en même temps est-ce que c pas.devenu ou en
train de devenir ça, le boulot du plus gd nombre ? On devient un peu tous
"intégrateurs" : qui oserait aujourd'hui faire un projet ss gérer les libs
externes, leurs dépendances... qui peut aujourd'hui écrire un algorithme de
tri au lieu d'en utiliser un ss que ce soit à la limite une faute
professionnelle ? Loin du mainstream à mon avis.

-- Baptiste

Post by Jean-Baptiste BRIAUD -- Novlog
C'est qu'à force de faire de la config et ne plus coder, on va finir par

.....

Post by Jean-Baptiste BRIAUD -- Novlog
argggll ... conf.xml.properties m'a tuer ...

Post by Baptiste MATHUS

Post by Sebastien Cesbron
Oui les ejbs amÚnent la démarcation tx mais là on la fait avec Spring

donc c'est équivalent

Post by Jean-Baptiste BRIAUD -- Novlog

Post by Baptiste MATHUS
À ma connaissance, intra-war, tout à fait. Inter-war c'est pas gagné. Ça

impliquerait d'avoir un ApplicationContext commun aux deux wars. Or,
partager des instances d'objet java entre wars d'un tomcat sans annuaire
jndi rw ça se complique.

Post by Jean-Baptiste BRIAUD -- Novlog

Post by Baptiste MATHUS

Post by Sebastien Cesbron
Sinon une autre question connexe par rapport à ce que disait Cedric. Si

je pars sur n modules qui ensembles vont générer un seul artefact de type
war : ce genre de configuration s'articule bien avec un environnement de dev
comme eclipse ? Le redéploiement pour tester une nouvelle version n'est pas
trop long ? On est obligé de passer par la génération d'un war maven ou bien
on est compatible wtp ?

Post by Jean-Baptiste BRIAUD -- Novlog

Post by Baptiste MATHUS
* M2eclipse + wtp. Utiliser les deux ensemble a longtemps été trÚs

compliqué. Heureusement, ça s'améliore à présent depuis plusieurs mois suite
à l'embauche de Fred Bricon par RedHat à plein temps pr bosser à
l'intégration des deux (m2e + wtp)

Post by Jean-Baptiste BRIAUD -- Novlog

Post by Baptiste MATHUS
* sinon, en fonction de tes contraintes je te conseillerais de regarder

du cÎté de webby. Projet créé par sonatype censé être plus simple et léger
que wtp pr faire du dev web ds Eclipse. Pas testé personnellement.

Post by Jean-Baptiste BRIAUD -- Novlog

Post by Baptiste MATHUS
-- Baptiste

[Jean-Baptiste BRIAUD -- Novlog]

Je suis un peu d'accord, ms en même temps est-ce que c pas.devenu ou en train de devenir ça, le boulot du plus gd nombre ? On devient un peu tous "intégrateurs" : qui oserait aujourd'hui faire un projet ss gérer les libs externes, leurs dépendances... qui peut aujourd'hui écrire un algorithme de tri au lieu d'en utiliser un ss que ce soit à la limite une faute professionnelle ? Loin du mainstream à mon avis.

On ne parle pas de la même chose. Tu parle de réutiliser, je parle d'arrêter de configurer mais de coder.
On veux faire sortir du code chaque variation de configuration mais on est en train de réinventer le code dans les multiples fichiers de configurations.
Sauf qu'il n'y a pas de compilo pour indiquer les erreurs et que c'est beaucoup moins rigoureux que le code.

J'en tire quelques conclusions :
1. Le code est donc trop complexe pour que l'on souhaite sortir tant de chose de ce code
2. L'approche actuelle a trop de bout de fichiers éparses et incohérents, autrement appelé fichiers de config
3. Echec de l'approche historique par les EJB et sa sauce piquante XML. Prise de conscience avec les EJB3. Remise dans le code d'une partie de la config, c'est bien.
4. Idem avec JPA. C'est bien, voire très bien.
5. Ca arrive bien tard, mais mieux vaux tard que jamais

En supposant l'existence d'environnement de DEV, TEST et PROD ...
Question peut-être un peu trop simple, mais pourquoi donc utiliser tout cet "attirail" en dev ?
Pourquoi ne pas laisser Eclipse tout builder, tout simplement, sans Maven ou autre, juste pour le "run du dev".

Je dirais : parce qu'on veut pas, qu'on ne doit pas refaire les mêmes choses à deux endroits.
Or déclarer par exemple tes dépendances, tes source folders, etc deux fois (une fois ds l'ide, une fois ds ton descripteur de build quel qu'il soit) est une hérésie.
On l'a vécu et cela nous a parfois conduit à avoir un war final contenant des versions de lib différentes de celles du dev.

De fait, tout redeviendrais plus simple : on change du code, on clique sur "run" et on voit se qui se passe.

Cf. Ci-dessus : pr moi c'est plus compliqué, donc, pas plus simple.

Ensuite, a partir du "run du test", on passe à l'artillerie lourde mais comme c'est automatique (à la Jenkins ou autre Teamcity), c'est moins grave.
Ca ne se configure qu'une seule fois sur une seule machine, le serveur de test.
De sorte qu'en production, tout à été testé avec les outils cibles type Maven et autre "bout de jar" qui composent une appli, voire même sur une architecture OSGI si la modularité est devenue un objectif plutôt u'un moyen.
Le problème, c'est qu'au bout d'un moment, on ne programme plus, on passe son temps précieux à configurer tout ce véritable bazar, et on s'étonnera, sûrement sincèrement, que les dev n'avancent pas aussi vite que prévu, qu'ils sont démotivés, ...

Je suis un peu d'accord, ms en même temps est-ce que c pas.devenu ou en train de devenir ça, le boulot du plus gd nombre ? On devient un peu tous "intégrateurs" : qui oserait aujourd'hui faire un projet ss gérer les libs externes, leurs dépendances... qui peut aujourd'hui écrire un algorithme de tri au lieu d'en utiliser un ss que ce soit à la limite une faute professionnelle ? Loin du mainstream à mon avis.
-- Baptiste

C'est qu'à force de faire de la config et ne plus coder, on va finir par .....
argggll ... conf.xml.properties m'a tuer ...

Oui les ejbs amènent la démarcation tx mais là on la fait avec Spring donc c'est équivalent

À ma connaissance, intra-war, tout à fait. Inter-war c'est pas gagné. Ça impliquerait d'avoir un ApplicationContext commun aux deux wars. Or, partager des instances d'objet java entre wars d'un tomcat sans annuaire jndi rw ça se complique.

Sinon une autre question connexe par rapport à ce que disait Cedric. Si je pars sur n modules qui ensembles vont générer un seul artefact de type war : ce genre de configuration s'articule bien avec un environnement de dev comme eclipse ? Le redéploiement pour tester une nouvelle version n'est pas trop long ? On est obligé de passer par la génération d'un war maven ou bien on est compatible wtp ?

* M2eclipse + wtp. Utiliser les deux ensemble a longtemps été très compliqué. Heureusement, ça s'améliore à présent depuis plusieurs mois suite à l'embauche de Fred Bricon par RedHat à plein temps pr bosser à l'intégration des deux (m2e + wtp)
* sinon, en fonction de tes contraintes je te conseillerais de regarder du côté de webby. Projet créé par sonatype censé être plus simple et léger que wtp pr faire du dev web ds Eclipse. Pas testé personnellement.
-- Baptiste

[Sebastien Cesbron]

C'est un peu la question que je me pose actuellement : comment architecturer
tout mon bazard pour que ce soit simple à la fois en dev et en prod et que
ce ne soit pas trop monolithique.

Le multi module c'est bien mais encore faut il que ça s'intègre bien dans
l'ide, d'après ce que j'ai compris ça devrait marcher pas trop mal mais je
vais tester quand même.

Autre point tant qu'on parle des env de PROD/TEST/DEV ... : Comment gérez
vous les spécificités de ces envs ?

Perso je vais mettre en place un PropertyPlaceholderConfigurer de Spring. Ca
fonctionne bien. Par contre niveau maven je cherche encore pour qu'à la
sortie mon fichier de conf soit externe à mon war. Je cherche encore la
bonne solution : certains ont des retours d'exp là dessus ?

Seb

Le 28 juillet 2011 13:52, Jean-Baptiste BRIAUD -- Novlog <

Je suis un peu d'accord, ms en même temps est-ce que c pas.devenu ou en
train de devenir ça, le boulot du plus gd nombre ? On devient un peu tous
"intégrateurs" : qui oserait aujourd'hui faire un projet ss gérer les libs
externes, leurs dépendances... qui peut aujourd'hui écrire un algorithme de
tri au lieu d'en utiliser un ss que ce soit à la limite une faute
professionnelle ? Loin du mainstream à mon avis.
On ne parle pas de la même chose. Tu parle de réutiliser, je parle
d'arrêter de configurer mais de coder.
On veux faire sortir du code chaque variation de configuration mais on est
en train de réinventer le code dans les multiples fichiers de
configurations.
Sauf qu'il n'y a pas de compilo pour indiquer les erreurs et que c'est
beaucoup moins rigoureux que le code.
1. Le code est donc trop complexe pour que l'on souhaite sortir tant de chose de ce code
2. L'approche actuelle a trop de bout de fichiers éparses et incohérents,
autrement appelé fichiers de config
3. Echec de l'approche historique par les EJB et sa sauce piquante XML.
Prise de conscience avec les EJB3. Remise dans le code d'une partie de la
config, c'est bien.
4. Idem avec JPA. C'est bien, voire très bien.
5. Ca arrive bien tard, mais mieux vaux tard que jamais
Le 28 juil. 2011 13:00, "Jean-Baptiste BRIAUD -- Novlog" <

Post by Jean-Baptiste BRIAUD -- Novlog
En supposant l'existence d'environnement de DEV, TEST et PROD ...
Question peut-être un peu trop simple, mais pourquoi donc utiliser tout

cet "attirail" en dev ?

Post by Jean-Baptiste BRIAUD -- Novlog
Pourquoi ne pas laisser Eclipse tout builder, tout simplement, sans Maven

ou autre, juste pour le "run du dev".
Je dirais : parce qu'on veut pas, qu'on ne doit pas refaire les mêmes
choses à deux endroits.
Or déclarer par exemple tes dépendances, tes source folders, etc deux fois
(une fois ds l'ide, une fois ds ton descripteur de build quel qu'il soit)
est une hérésie.
On l'a vécu et cela nous a parfois conduit à avoir un war final contenant
des versions de lib différentes de celles du dev.

Post by Jean-Baptiste BRIAUD -- Novlog
De fait, tout redeviendrais plus simple : on change du code, on clique

sur "run" et on voit se qui se passe.
Cf. Ci-dessus : pr moi c'est plus compliqué, donc, pas plus simple.

Post by Jean-Baptiste BRIAUD -- Novlog
Ensuite, a partir du "run du test", on passe à l'artillerie lourde mais

comme c'est automatique (à la Jenkins ou autre Teamcity), c'est moins grave.

Post by Jean-Baptiste BRIAUD -- Novlog
Ca ne se configure qu'une seule fois sur une seule machine, le serveur de

test.

Post by Jean-Baptiste BRIAUD -- Novlog
De sorte qu'en production, tout à été testé avec les outils cibles type

Maven et autre "bout de jar" qui composent une appli, voire même sur une
architecture OSGI si la modularité est devenue un objectif plutôt u'un
moyen.

Post by Jean-Baptiste BRIAUD -- Novlog
Le problème, c'est qu'au bout d'un moment, on ne programme plus, on passe

son temps précieux à configurer tout ce véritable bazar, et on s'étonnera,
sûrement sincèrement, que les dev n'avancent pas aussi vite que prévu,
qu'ils sont démotivés, ...
Je suis un peu d'accord, ms en même temps est-ce que c pas.devenu ou en
train de devenir ça, le boulot du plus gd nombre ? On devient un peu tous
"intégrateurs" : qui oserait aujourd'hui faire un projet ss gérer les libs
externes, leurs dépendances... qui peut aujourd'hui écrire un algorithme de
tri au lieu d'en utiliser un ss que ce soit à la limite une faute
professionnelle ? Loin du mainstream à mon avis.
-- Baptiste

Post by Jean-Baptiste BRIAUD -- Novlog
C'est qu'à force de faire de la config et ne plus coder, on va finir par

.....

Post by Jean-Baptiste BRIAUD -- Novlog
argggll ... conf.xml.properties m'a tuer ...

Oui les ejbs amènent la démarcation tx mais là on la fait avec Spring

donc c'est équivalent

Post by Jean-Baptiste BRIAUD -- Novlog

À ma connaissance, intra-war, tout à fait. Inter-war c'est pas gagné. Ça

impliquerait d'avoir un ApplicationContext commun aux deux wars. Or,
partager des instances d'objet java entre wars d'un tomcat sans annuaire
jndi rw ça se complique.

Post by Jean-Baptiste BRIAUD -- Novlog

Sinon une autre question connexe par rapport à ce que disait Cedric.

Si je pars sur n modules qui ensembles vont générer un seul artefact de type
war : ce genre de configuration s'articule bien avec un environnement de dev
comme eclipse ? Le redéploiement pour tester une nouvelle version n'est pas
trop long ? On est obligé de passer par la génération d'un war maven ou bien
on est compatible wtp ?

Post by Jean-Baptiste BRIAUD -- Novlog

* M2eclipse + wtp. Utiliser les deux ensemble a longtemps été très

compliqué. Heureusement, ça s'améliore à présent depuis plusieurs mois suite
à l'embauche de Fred Bricon par RedHat à plein temps pr bosser à
l'intégration des deux (m2e + wtp)

Post by Jean-Baptiste BRIAUD -- Novlog

* sinon, en fonction de tes contraintes je te conseillerais de regarder

du côté de webby. Projet créé par sonatype censé être plus simple et léger
que wtp pr faire du dev web ds Eclipse. Pas testé personnellement.

Post by Jean-Baptiste BRIAUD -- Novlog

-- Baptiste

[p***@orange-ftgroup.com]

Dans notre cas les fichiers de properties sont cherchés dans le classpath et on en a 2 versions :
Une « par défaut », dans les .war
Et une « customisée » dans $JONAS_HOME/notreProduit/conf
On a configuré Jonas de telle sorte que $JONAS_HOME/notreProduit/conf soit dans le classpath et pris en priorité (j'ignore les détails techniques).

Ca marche pas mal comme ça.

J'ai aussi procédé de la sorte avec des déploiement dans Fuse ESB.

My 2 cents,
Patrice


De : Sebastien Cesbron [mailto:***@gmail.com]
Envoyé : jeudi 28 juillet 2011 15:49
À : java Java
Objet : Re: Coder ou configurer was Re: Partager un modèle jpa entre plusieurs war

C'est un peu la question que je me pose actuellement : comment architecturer tout mon bazard pour que ce soit simple à la fois en dev et en prod et que ce ne soit pas trop monolithique.

Le multi module c'est bien mais encore faut il que ça s'intègre bien dans l'ide, d'après ce que j'ai compris ça devrait marcher pas trop mal mais je vais tester quand même.

Autre point tant qu'on parle des env de PROD/TEST/DEV ... : Comment gérez vous les spécificités de ces envs ?

Perso je vais mettre en place un PropertyPlaceholderConfigurer de Spring. Ca fonctionne bien. Par contre niveau maven je cherche encore pour qu'à la sortie mon fichier de conf soit externe à mon war. Je cherche encore la bonne solution : certains ont des retours d'exp là dessus ?



********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************

[Jean-Baptiste BRIAUD -- Novlog]

Je dirais : parce qu'on veut pas, qu'on ne doit pas refaire les mêmes choses à deux endroits.
Or déclarer par exemple tes dépendances, tes source folders, etc deux fois (une fois ds l'ide, une fois ds ton descripteur de build quel qu'il soit) est une hérésie.
On l'a vécu et cela nous a parfois conduit à avoir un war final contenant des versions de lib différentes de celles du dev.

Oui, c'est une bonne remarque, mais çà ne réponds en rien à l'objection : on impose au dev trop de contorsion pour des raisons en fait techniques ou liées à des limitations techniques, mais non pas pour de bonnes raisons souhaitables.
Le développeur deviens une sorte de formule 1 dans un circuit de course d'escargot.

Perds t-on plus de temps à configurer une seule fois les dépendances 2 fois ou bien à lancer la build de quelques minutes toutes les quelques minutes ?

En supposant l'existence d'environnement de DEV, TEST et PROD ...
Question peut-être un peu trop simple, mais pourquoi donc utiliser tout cet "attirail" en dev ?
Pourquoi ne pas laisser Eclipse tout builder, tout simplement, sans Maven ou autre, juste pour le "run du dev".

Je dirais : parce qu'on veut pas, qu'on ne doit pas refaire les mêmes choses à deux endroits.
Or déclarer par exemple tes dépendances, tes source folders, etc deux fois (une fois ds l'ide, une fois ds ton descripteur de build quel qu'il soit) est une hérésie.
On l'a vécu et cela nous a parfois conduit à avoir un war final contenant des versions de lib différentes de celles du dev.

De fait, tout redeviendrais plus simple : on change du code, on clique sur "run" et on voit se qui se passe.

Cf. Ci-dessus : pr moi c'est plus compliqué, donc, pas plus simple.

Ensuite, a partir du "run du test", on passe à l'artillerie lourde mais comme c'est automatique (à la Jenkins ou autre Teamcity), c'est moins grave.
Ca ne se configure qu'une seule fois sur une seule machine, le serveur de test.
De sorte qu'en production, tout à été testé avec les outils cibles type Maven et autre "bout de jar" qui composent une appli, voire même sur une architecture OSGI si la modularité est devenue un objectif plutôt u'un moyen.
Le problème, c'est qu'au bout d'un moment, on ne programme plus, on passe son temps précieux à configurer tout ce véritable bazar, et on s'étonnera, sûrement sincèrement, que les dev n'avancent pas aussi vite que prévu, qu'ils sont démotivés, ...

Je suis un peu d'accord, ms en même temps est-ce que c pas.devenu ou en train de devenir ça, le boulot du plus gd nombre ? On devient un peu tous "intégrateurs" : qui oserait aujourd'hui faire un projet ss gérer les libs externes, leurs dépendances... qui peut aujourd'hui écrire un algorithme de tri au lieu d'en utiliser un ss que ce soit à la limite une faute professionnelle ? Loin du mainstream à mon avis.
-- Baptiste

C'est qu'à force de faire de la config et ne plus coder, on va finir par .....
argggll ... conf.xml.properties m'a tuer ...

Oui les ejbs amènent la démarcation tx mais là on la fait avec Spring donc c'est équivalent

À ma connaissance, intra-war, tout à fait. Inter-war c'est pas gagné. Ça impliquerait d'avoir un ApplicationContext commun aux deux wars. Or, partager des instances d'objet java entre wars d'un tomcat sans annuaire jndi rw ça se complique.

Sinon une autre question connexe par rapport à ce que disait Cedric. Si je pars sur n modules qui ensembles vont générer un seul artefact de type war : ce genre de configuration s'articule bien avec un environnement de dev comme eclipse ? Le redéploiement pour tester une nouvelle version n'est pas trop long ? On est obligé de passer par la génération d'un war maven ou bien on est compatible wtp ?

* M2eclipse + wtp. Utiliser les deux ensemble a longtemps été très compliqué. Heureusement, ça s'améliore à présent depuis plusieurs mois suite à l'embauche de Fred Bricon par RedHat à plein temps pr bosser à l'intégration des deux (m2e + wtp)
* sinon, en fonction de tes contraintes je te conseillerais de regarder du côté de webby. Projet créé par sonatype censé être plus simple et léger que wtp pr faire du dev web ds Eclipse. Pas testé personnellement.
-- Baptiste

[Rémi Forax]

Moi, je dirais que le dev doit inquer les dépendences avec les librairies
externes dans son code. Que le compilo doit comprendre ces dépendences
et calculer l'ensemble des dépendances de l'appli pour générer le(s)
descripteur(s)
de déploiement.

en un mot: Jigsaw.

Rémi
Maven is dead

Post by Jean-Baptiste BRIAUD -- Novlog

Post by Baptiste MATHUS

Post by Baptiste MATHUS
Je dirais : parce qu'on veut pas, qu'on ne doit pas refaire les
mêmes choses à deux endroits.
Or déclarer par exemple tes dépendances, tes source folders, etc
deux fois (une fois ds l'ide, une fois ds ton descripteur de build
quel qu'il soit) est une hérésie.
On l'a vécu et cela nous a parfois conduit à avoir un war final
contenant des versions de lib différentes de celles du dev.

Oui, c'est une bonne remarque, mais çà ne réponds en rien à
l'objection : on impose au dev trop de contorsion pour des raisons en
fait techniques ou liées à des limitations techniques, mais non pas
pour de bonnes raisons souhaitables.
Le développeur deviens une sorte de formule 1 dans un circuit de course d'escargot.
Perds t-on plus de temps à configurer une seule fois les dépendances 2
fois ou bien à lancer la build de quelques minutes toutes les quelques
minutes ?

Post by Baptiste MATHUS
Le 28 juil. 2011 13:00, "Jean-Baptiste BRIAUD -- Novlog"

Post by Baptiste MATHUS
En supposant l'existence d'environnement de DEV, TEST et PROD ...
Question peut-être un peu trop simple, mais pourquoi donc utiliser

tout cet "attirail" en dev ?

Post by Baptiste MATHUS
Pourquoi ne pas laisser Eclipse tout builder, tout simplement, sans

Maven ou autre, juste pour le "run du dev".
Je dirais : parce qu'on veut pas, qu'on ne doit pas refaire les mêmes
choses à deux endroits.
Or déclarer par exemple tes dépendances, tes source folders, etc deux
fois (une fois ds l'ide, une fois ds ton descripteur de build quel
qu'il soit) est une hérésie.
On l'a vécu et cela nous a parfois conduit à avoir un war final
contenant des versions de lib différentes de celles du dev.

Post by Baptiste MATHUS
De fait, tout redeviendrais plus simple : on change du code, on

clique sur "run" et on voit se qui se passe.
Cf. Ci-dessus : pr moi c'est plus compliqué, donc, pas plus simple.

Post by Baptiste MATHUS
Ensuite, a partir du "run du test", on passe à l'artillerie lourde

mais comme c'est automatique (à la Jenkins ou autre Teamcity), c'est
moins grave.

Post by Baptiste MATHUS
Ca ne se configure qu'une seule fois sur une seule machine, le

serveur de test.

Post by Baptiste MATHUS
De sorte qu'en production, tout à été testé avec les outils cibles

type Maven et autre "bout de jar" qui composent une appli, voire même
sur une architecture OSGI si la modularité est devenue un objectif
plutôt u'un moyen.

Post by Baptiste MATHUS
Le problème, c'est qu'au bout d'un moment, on ne programme plus, on

passe son temps précieux à configurer tout ce véritable bazar, et on
s'étonnera, sûrement sincèrement, que les dev n'avancent pas aussi
vite que prévu, qu'ils sont démotivés, ...
Je suis un peu d'accord, ms en même temps est-ce que c pas.devenu ou
en train de devenir ça, le boulot du plus gd nombre ? On devient un
peu tous "intégrateurs" : qui oserait aujourd'hui faire un projet ss
gérer les libs externes, leurs dépendances... qui peut aujourd'hui
écrire un algorithme de tri au lieu d'en utiliser un ss que ce soit à
la limite une faute professionnelle ? Loin du mainstream à mon avis.
-- Baptiste

Post by Baptiste MATHUS
C'est qu'à force de faire de la config et ne plus coder, on va

finir par .....

Post by Baptiste MATHUS
argggll ... conf.xml.properties m'a tuer ...

Oui les ejbs amènent la démarcation tx mais là on la fait avec

Spring donc c'est équivalent

Post by Baptiste MATHUS

À ma connaissance, intra-war, tout à fait. Inter-war c'est pas

gagné. Ça impliquerait d'avoir un ApplicationContext commun aux deux
wars. Or, partager des instances d'objet java entre wars d'un tomcat
sans annuaire jndi rw ça se complique.

Post by Baptiste MATHUS

Sinon une autre question connexe par rapport à ce que disait

Cedric. Si je pars sur n modules qui ensembles vont générer un seul
artefact de type war : ce genre de configuration s'articule bien avec
un environnement de dev comme eclipse ? Le redéploiement pour tester
une nouvelle version n'est pas trop long ? On est obligé de passer
par la génération d'un war maven ou bien on est compatible wtp ?

Post by Baptiste MATHUS

* M2eclipse + wtp. Utiliser les deux ensemble a longtemps été très

compliqué. Heureusement, ça s'améliore à présent depuis plusieurs
mois suite à l'embauche de Fred Bricon par RedHat à plein temps pr
bosser à l'intégration des deux (m2e + wtp)

Post by Baptiste MATHUS

* sinon, en fonction de tes contraintes je te conseillerais de

regarder du côté de webby. Projet créé par sonatype censé être plus
simple et léger que wtp pr faire du dev web ds Eclipse. Pas testé
personnellement.

Post by Baptiste MATHUS

-- Baptiste

[Cédric Beust ♔]

Post by Rémi Forax
**
en un mot: Jigsaw.
Rémi
Maven is dead

Et Jigsaw n'est pas encore né :-)

[Rémi Forax]

Post by Rémi Forax
en un mot: Jigsaw.
Rémi
Maven is dead
Et Jigsaw n'est pas encore né :-)

disons qu'il est en gestation :)
http://openjdk.java.net/projects/jigsaw/

Post by Rémi Forax
--
Cédric

Rémi