Re: Partager un modèle jpa entre plusieurs war

Baptiste MATHUS <[email protected]> Thu, 28 Jul 2011 13:43:59 +0200
Newsgroups gmane.comp.java.french.general
Message-ID <CANWgJS5aomCz3icW7yxakCLq36sCZDYAUQRwevo75nAca0WCFA@mail.gmail.com>
Le 28 juil. 2011 13:00, "Jean-Baptiste BRIAUD -- Novlog" <
[email protected]> a écrit :
>
> 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 ...
>
>
>
> On 28 juil. 2011, at 12:39, Baptiste MATHUS wrote:
>
>>
>> Le 27 juil. 2011 16:57, "Sebastien Cesbron" <[email protected]> a
écrit :
>> >
>> > 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 ?
>>
>> 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
>
>