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 ?

Seb

Le 28 juillet 2011 13:52, Jean-Baptiste BRIAUD -- Novlog <
[email protected]> a écrit :

> 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
>
> On 28 juil. 2011, at 13:43, Baptiste MATHUS wrote:
>
>
> 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
> >
> >
>
>
>