Re: Partager un modèle jpa entre plusieur s war

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

On 07/28/2011 01:56 PM, Jean-Baptiste BRIAUD -- Novlog wrote:
>>>
>>> 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 ?
>
> On 28 juil. 2011, at 13:43, Baptiste MATHUS wrote:
>
>>
>> Le 28 juil. 2011 13:00, "Jean-Baptiste BRIAUD -- Novlog" 
>> <[email protected] <mailto:[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] 
>> <mailto:[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
>> >
>> >
>>
>