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

[Eric NOULARD]

Le dimanche 06 mars 2005 à 09:18 -0500, Stephane Galles a écrit :
> Non, non, ce n'est pas du détail, le cas d'utilisation que tu décrit
> me semble vraiment important. Je suis parfaitement d'accord avec
> l'idée du jstdout dans jtsp.jar (et avec jstub, donc, puisqu'il s'appel 
> ainsi !)

Evidemment ça me fait plaisir que tu penses ça :))

Le jstub est virtuel donc appelons-le comme on veut :))
Il pourrait aussi s'appeler jstubprovider j'avoue que j'aime
plus le nom de notre 'stub_server' C car c'est d'abord un 'provider'
le côté serveur est 'perturbant' car même si aujourd'hui on 
est client/serveur c'est plus l'implémentation C + RPC 
qui donne à TSP la tronche client/serveur.

Avec un provider scotché à un blackboard c'est déjà moins
simple de voir qui est 
le 'serveur' [dans mon idée celui qui les possède et les crée]
des symboles.
En revanche le provider sera toujours le 'fournisseur' des symboles.

bon là je divague par rapport à jtsp...

> 
> D'autant plus que ces deux là ne dépendent pas d'une autre lib
> externe, ils sont donc utilisables out of the box via jtsp.jar
> 
> On a donc 2 votes pour :
> - jtsp.jar le core tsp, avec jstdout et jstub   (ne dépend que de RemoteTea)
> - jtsp-tools.jar pour les autres consumers/provider qui tirent toutes
> les lib externes qui veulent sachant qu'en java on peut se contenter
> de ne déployer que les lib des fonctionnalités dont on a besoin
> 
> Pour information, ce type de découpage est trés employé. Par
> exemple, un des plus beaux projets open source du web en java
> fait exactement comme cela (c'est aussi pour cela que j'avais
> pensé à ça) : http://www.hibernate.org/6.html
> 
> Steph
> 
> Eric NOULARD wrote:
> 
> >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
> >>>
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >
> >
> >
> >_______________________________________________
> >Tsp-devel mailing list
> >address@hidden
> >http://lists.nongnu.org/mailman/listinfo/tsp-devel
> >
> >
> >  
> >
>