tsp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: dvp.duf
Subject: Re: [Fwd: [Tsp-devel] Découpage des jar d e JTSP ...once again...]
Date: Sun, 06 Mar 2005 18:08:09 +0100
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]