Re: [Fwd: [Tsp-devel] Découpage des jar de JTSP ...once again...]

[Eric NOULARD]

Personnellement je suis d'accord avec la solution 2.

jtsp.jar avec le core tsp 
jstp-tools.jar pour les consumers/provider.

Je me demande juste si ça vaudrait pas le coup d'avoir
1 provider et 1 consumer intégré, "builtin" à jtsp.jar.

Je m'explique le type qui va développer son provider/consumer
avec Jtsp ne prendra que le jtsp.jar et pis si il a un pb avec
son consumer/provider en cours de dév il n'aura pas d'autre
choix que de prendre les jtsp-tools.jar pour vérifier avec
un consumer/provider DE CONFIANCE, par exemple jstdout/jstub
que c'est bien SON consumer/provider qui déconne et pas jtsp.

Je pense, personnellement, que c'est utile, d'embarquer dans sa lib
un minimum d'outils qui permette de la "débugger/investiguer/etc..."
et surtout une fois l'appli déployée.

Genre j'ai déployé mon tout nouveau tout beau consumer,
jsuisjreste, donc mon client préféré est en possession sur son site
opérationnel de: jtsp.jar jsuisjreste.jar.
jsuisjreste déconne visiblement, ben je peux pas lui demander 
de tester "simplement" un petit coup de jstdout (en qui j'ai toute 
confiance vu que ça fait 5 ans qu'il marche et qu'il passe à tout coup
son JUnit préféré).

Donc en résumé je suis d'accord avec Stéphane mais je ferais 1 variante:

jtsp.jar = core tsp + 1 consumer simple et fiable + 1 provider simple et
fiable
jtsp-tools.jar = l'ensemble des consumers/providers

Je propose que le consumer simple et fiable soit jstdout
et que le provider fiable (quand il existera) soit jstub.

Maintenant je pense qu'on est dans le détail, donc
la solution N°2 de Stéphane me va très bien également.

Eric


Le samedi 05 mars 2005 à 22:29 -0500, Stephane Galles a écrit :
> Effectivement, le classloader est assez malin pour qu'on puisse mettre
> jsynoptic-plugin dans jtsp.jar sans que cela ne gène ceux qui ne veulent
> pas l'utiliser.
> 
> Mon email correctif soulignait la dépendance sur jsynoptic.jar, mais
> comme tu l'a précisé, UNIQUEMENT si on veut utiliser le jsynoptic-plugin.
> Du coup, effectivement, tu a été plus loin que moi, et je suis d'accord !
> 
> On peut donc TOUT mettre dans jstp.jar, et en poussant le bouchon, y compris
> jcdfwriter (et comme pour jsynoptic-plugin, si on veut l'utiliser il 
> suffit d'ajouter
> le jar cdf)
> 
> Du coup cela me fait penser à une variation de cette solution qui ressemble
> à ce qui a été fait sur les librairies cdf : On pourrait faire 2 jar, 
> mais uniquement
> 2  et seulement 2 :
> 
> - jtsp.jar = core, util, provider, consumer autrement dit le coeur de tsp
> - jtsp-tools.jar = jstdout, jsynoptic-plugin, jcdfwriter, et tout les 
> consumers et provider
> qui s'appuiront sur jtsp.jar et codés par l équipe TSP
> 
> L'idée est que cela permet de faire grossir autant que l'on veut 
> jtsp-tools.jar sans
> impacter ceux qui veulent simplement profiter de jtsp.jar pour faire 
> leur propre
> consumer ou provider. On aura moins de scrupules à ajouter plein de consumer
> ou provider dans la tool-box, et le jar principal restera propre
> Si on met trop de chose dans la librairie principale, le nombre de 
> classes publiques
> va augmenter, et cela risque d'effrayer les utilisateur qui veulent 
> simplement
> coder leur propre consumer/provider, en noyant les vraies classes 
> importantes.
> 
> Donc, si quelqu'un veut implémenter un nouveau consumer/provider, il lui 
> suffit
> d'avoir jtsp.jar (et le jar de RemoteTea indispensable pour jtsp.jar)
> 
> Et si quelqu'un veut essayer un de nos outils, il prend jtsp-tools.jar, 
> jtsp.jar ( et RemoteTea),
> et il ajoute UNIQUEMENT ce que l'outil en question nécessite si necessaire
> (jar cdf, jar jsynoptic, etc...)
> 
> Je sent qu'on converge, mais étant donné que je viens d'ajouter une 
> alternative il faut maitenant
> choisir entre :
> 
> - jtsp.jar avec tout l'univers dedans
> - ou jtsp.jar + jtsp-tools.jar
> 
> personnellement j'aime bien la 2eme solution  :)
> mais je reste ouvert, bien sur !
> 
> Steph
> 
> 
> Eric NOULARD wrote:
> 
> >En fait faisant un peu de Java en ce moment, je suis....
> >
> >POUR.
> >
> >En effet, c'est un peu pénible d'avoir à saucissonner un truc qui
> >se tient ça ne vaut EFFECTIVEMENT que dans le cas ou
> >
> >partie A dépend de RIEN
> >partie B dépend de Toto.
> >
> >dans ce cas celui qui veut utiliser A se tire la dépendance avec Toto
> >et c'est pas bien.
> >
> >Dans le cas de jtsp on dépends pour l'instant de rien sauf de la version
> >du JDK donc OUI pour jtsp.jar avec tout dedans 
> >(sauf le plugin jsynoptic).
> >
> >Maintenant j'irais même plus loin, 
> >pourquoi pas TOUT mettre dedans y compris jsynoptic-plugin.
> >
> >En effet, je pense que le chargeur de classe Java est relativement malin
> >(et là j'ai la flemme de faire le test quand 
> >Stéphane aura sûrement la réponse)
> >et qu'il ne viendra pas embêter celui qui utilise jstdout
> >et ce même si jtsp.jar contient jsynoptic-plugins?
> >
> >Est-ce que je me trompe?
> >
> >Si je me trompe et que le fait d'avoir 1 dependance dans un jar
> >inflige la dépendance à tout ce qui est dans le jar alors
> >jtsp.jar total SAUF jsynoptic.
> >D'ailleurs me vient à l'esprit que le plugins ne sert à rien
> >SANS jsynoptic donc ça sert à rien de le mettre dans jtsp.jar.
> >
> >Sinon euh qu'en est-il de RemoteTea?
> >
> >Comme vous le voyez à mes dépends ça fait un moment que j'ai pas
> >joué avec jtsp (shame on me) mais ça va revenir.
> >
> >En bref je suis POUR qu'on mette le maximum de chose dans un seul
> >jar tant qu'on inflige pas des dépendances inutiles à ceux qui n'en
> >veulent pas.
> >
> >C'est un peu la philo de Bjarne Stroustrup pour les 'features' C++:
> >
> >On ne doit pas payer pour qqchose qu'on a pas acheté :))
> >
> >Eric
> >
> >Le samedi 05 mars 2005 à 09:39 -0500, Stephane Galles a écrit :
> >  
> >
> >>Petit correctif...
> >>
> >>Évidemment on ne peut pas mettre jsynoptic-plugin dans le jtsp.jar puisqu'il
> >>a des dépendances sur le jar de jsynoptic...
> >>
> >>Je m'emballe des fois...Faut plus que j'écrire d'email le samedi matin 
> >>sans avoir
> >>pris mon café.
> >>
> >>Mais bon, le jtsp.jar consumer-provider-jstdout tiens toujours !
> >>
> >>Re-Réactions ?
> >>
> >>Steph
> >>
> >>pièce jointe Email message ([Tsp-devel]
> >>=?ISO-8859-1?Q?D=E9coupage_des_jar_de_JTSP_=2E=2E=2E?==?ISO-8859-1?Q?once_again=2E=2E=2E?=)
> >>Le samedi 05 mars 2005 à 09:39 -0500, Stephane Galles a écrit :
> >>_______________________________________________
> >>Tsp-devel mailing list
> >>address@hidden
> >>http://lists.nongnu.org/mailman/listinfo/tsp-devel
> >>    
> >>
> >
> >
> >
> >_______________________________________________
> >Tsp-devel mailing list
> >address@hidden
> >http://lists.nongnu.org/mailman/listinfo/tsp-devel
> >
> >
> >  
> >
>