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

[Stephane Galles]

Le pseudo-configure Ant ne sera pas là pour t'interdire de compiler.

Pour compiler il y a juste besoin du jar CDF cdfjava.jar , et il sera
présent dans tous les cas, car on pourra le fournir dans CVS (il ne fait 
que 61Ko...)
(on va juste vérifier la license quand meme !)

Eventuellement, le pseudo-configure Ant pourra indiquer que la
lib native n'est pas présente, et que tu peux compiler, mais tu
ne pourra pas executer. Un warning, donc.

dvp.duf wrote:

> Moi je dit : Oui à jtsp et son jstp-tools ! C'est bon le KISS
>
> Par contre si avec CDF (qui ira dans les tools n'en doutons pas) je 
> tire une lib dynamique OS dépendante ? Je pense que le "lazy" loader 
> de java fera correctement le boulot, mais le configure va peut-etre 
> m'interdire de compiler toutes les tools ? A voir.
> Y++
>
> Stephane Galles wrote:
> Stephane Galles wrote:
>
> > 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
>
>
>
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel