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

[Eric NOULARD]

Pas de pb pour ces modifs en ce qui me concernent
elles sont pertinentes, comme d'hab :))

Le dimanche 06 mars 2005 à 11:26 -0500, Stephane Galles a écrit :
> OK, juste en passant un peu de feedback sur l'arbo, car je me suis permi 
> d'ajouter
> une ou deux choses (marqué par les "Modif")
> 
> - app : Pour que le contenu du package tsp.consumer soit homogène
> - util : pour mettre les choses genre, imaginons, un Décorateur
> de l'API consumer (=Wrapper pour ceux qui n'aime pas les
> Design Patterns :)  ) qui permette l'agregation des symboles
> avec synchro du temps
> - src_test : le nom standard de l'emplacement des sources des tests
> junit
> 
> Ce sont des petites modifs, mais je préfère vous en faire part car l'arbo
> c'est important ! (surtout dans CVS avec ce que l'on sait sur la gestion
> des répertoires ...)
> 
> jtsp
> |-- build
> |   |-- class
> |   `-- jar
> |-- lib
> |   |-- RemoteTea
> |   |-- cdf
> |   `-- jSynoptic
> |-- src
> |   `-- tsp
> |       |-- consumer
> |       |   |-- app                                     <-- Modif
> |       |   |   |-- jcdfwriter
> |       |   |   `-- jstdout
> |       |   |-- plugin
> |       |   |   `-- jsynoptic
> |       |   |       |-- impl
> |       |   |       `-- ui
> |       |   |           `-- ressources
> |       |   `-- util                                   <-- Modif
> |       |-- core
> |       |   |-- common
> |       |   |   |-- url
> |       |   |   `-- xml
> |       |   |-- config
> |       |   |-- consumer
> |       |   |-- provider
> |       |   `-- rpc
> |       |-- provider
> |       `-- util
> `-- src_test                                       <-- Modif
>   
> 
> 
> Eric NOULARD wrote:
> 
> >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
> >>>
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >
> >
> >
> >_______________________________________________
> >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
>