|
From: | Stephane Galles |
Subject: | Re: [Fwd: [Tsp-devel] Découpage des jar d e JTSP ...once again...] |
Date: | Sun, 06 Mar 2005 11:26:06 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 |
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 avecl'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à moinssimple 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 coupson 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 comprisjcdfwriter (et comme pour jsynoptic-plugin, si on veut l'utiliser il suffit d'ajouterle 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 uniquement2 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 providerqui s'appuiront sur jtsp.jar et codés par l équipe TSPL'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 propreconsumer ou provider. On aura moins de scrupules à ajouter plein de consumer ou provider dans la tool-box, et le jar principal restera propreSi 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 suffitd'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 maitenantchoisir 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 versiondu 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 avoirpris 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
[Prev in Thread] | Current Thread | [Next in Thread] |