Coder ou configurer was Re: Partager un modèl e jpa entre plusieurs war

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