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