RE: RE : [Tsp-devel] Java : TSP-CDF-Writer

[TSP]

Comme d'hab, ma préference c'est "Le + simple"=> KISS !!!
Donc 4 modules doc + ctsp + jtsp + external et tsp = all.
Mais comme je lit mes mails en 3s, j'ai sans doute une vision trop simple du
pb.
Y++


> -----Original Message-----
> From: Eric NOULARD [mailto:address@hidden
> Sent: Tuesday, March 01, 2005 12:04 AM
> To: Devel TSP
> Subject: Re: RE : [Tsp-devel] Java : TSP-CDF-Writer
> 
> 
> Bon voilà j'ai fait quelques tests 
> de modularisation CVS mais j'ai besoin de votre avis:
> 
> Ci-joint un zip (MyRepo.zip) qui contient le dépôt de test.
> A détarrer qque part:
> 
> mkdir /tmp/TEST_REPO
> cd /tmp/TEST_REPO
> unzip MyRepo.zip
> 
> Ensuite on se met "ailleurs"
> mkdir /tmp/TEST_CO
> cd /tmp/TEST_CO
> 
> on positionne la variable CVSROOT (ou on passe -d aux commande qui
> suivront):
> export CVSROOT=/tmp/TEST_REPO/MyRepo
> 
> Puis vous pouvez tester les commandes qui suivent et 
> vous devriez voir si le principe de la modularisation vous
> va.
> 
> [Ci-joint un auuutrrre zip (test_cvs.zip) qui contient 
>  le résultat des commandes qui suivent chez moi au cas
>  ou ça marcherait pas chez vous :))]
> 
> ma variable CVSROOT est positionnee correctement 
> puis j'ai fait:
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> address@hidden TEST_CO]$ cvs co CVSROOT
> cvs checkout: Updating CVSROOT
> U CVSROOT/checkoutlist
> U CVSROOT/commitinfo
> U CVSROOT/config
> U CVSROOT/cvswrappers
> U CVSROOT/editinfo
> U CVSROOT/loginfo
> U CVSROOT/modules
> U CVSROOT/notify
> U CVSROOT/rcsinfo
> U CVSROOT/taginfo
> U CVSROOT/verifymsg
> address@hidden TEST_CO]$
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> address@hidden TEST_CO]$ cvs co tsp
> cvs checkout: Updating tsp
> U tsp/README
> address@hidden TEST_CO]$
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> address@hidden TEST_CO]$ cvs co jtsp_all
> cvs checkout: Updating jtsp
> cvs checkout: Updating jtsp/tsp
> cvs checkout: Updating jtsp/tsp/core
> cvs checkout: Updating jtsp/tsp/core/consumer
> U jtsp/tsp/core/consumer/README
> cvs checkout: Updating jexternal
> U jexternal/README
> cvs checkout: Updating jtsp/tsp/consumer/jstdout
> U jtsp/tsp/consumer/jstdout/README
> cvs checkout: Updating jtsp/tsp/consumer/jsynoptic-plugins
> U jtsp/tsp/consumer/jsynoptic-plugins/README
> cvs checkout: Updating jtsp/tsp/consumer/jcdfwriter
> U jtsp/tsp/consumer/jcdfwriter/README
> address@hidden TEST_CO]$
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> address@hidden TEST_CO]$ cvs co tsp_all
> cvs checkout: Updating tsp_whitepaper
> U tsp_whitepaper/README
> cvs checkout: Updating tsp_bbguide
> U tsp_bbguide/README
> cvs checkout: Updating tsp
> U tsp/README
> cvs checkout: Updating jtsp
> cvs checkout: Updating jtsp/tsp
> cvs checkout: Updating jtsp/tsp/core
> cvs checkout: Updating jtsp/tsp/core/consumer
> U jtsp/tsp/core/consumer/README
> cvs checkout: Updating jexternal
> U jexternal/README
> cvs checkout: Updating jtsp/tsp/consumer/jstdout
> U jtsp/tsp/consumer/jstdout/README
> cvs checkout: Updating jtsp/tsp/consumer/jsynoptic-plugins
> U jtsp/tsp/consumer/jsynoptic-plugins/README
> cvs checkout: Updating jtsp/tsp/consumer/jcdfwriter
> U jtsp/tsp/consumer/jcdfwriter/README
> address@hidden TEST_CO]$
> 
> 
> Si vous êtes allés jusqu'au bout c'est que vous êtes des warrior
> de la modularisation CVS, les plus curieux peuvent
> jeter un oeil au fichier: CVSROOT/modules pour mieux 
> comprendre comment ça marche.
> 
> Avant de faire la demande (ou pas suivant vos avis) 
> aux savannah-hackers je dois avoir
> un retour du maximum d'entre vous.
> 
> Les impacts positifs:
> - checkout modulaire plus simple
> - separation des modules qui sont bien tout seuls
>   (jtsp, doc, tsp C, ...)
> - quasiment aucun impact sur le module 'tsp' actuel
>   sauf qu'on met jtsp à côté.
> - creation de tsp_all, tsp_doc
> - on remet d'equerre l'arbo de jtsp (jstdout et autres consumer à leur
> place)
> 
> Les impacts négatifs:
> - on mets jtsp à côté :))
> - si on veut rajouter un modules de haut niveau on 
>   peut mais si on veut updater/changer le fichier
>   CVSROOT/modules ben il faut passer par savannah-hackers.
>    ==> manque d'autonomie.
> - la récursion dans les répertoires au niveau du build
>   pourrait être moins simple car il faut tester
>   la présence ou non des répertoires agrégé.
>   Je pense qu'avec Ant c'est simple avec Make faut voir...
>   Mais pour l'instant le module tsp ne change pas donc...
>   les problèmes viendront plus tard, quand on compilera
>   le C aussi avec Ant :))
> 
> Une option plus simple et hummm efficace serait de créer
> UNIQUEMENT un nouveau module de haut niveau appelé 
> jtsp qui contienne tout le Java comme 'tsp' contient
> tout le C aujourd'hui et on degage 'juste' le java 
> de l'arbo actuelle.
> 
> A bien y réfléchir la dernière solution est tentante
> car simplissime et on garde une autonomie de gestion,
> ce qui ne nous empêches pas de demander 2 modules:
> 
> tsp_doc  == les modules de doc
> 
> tsp_all  == tout tsp == tsp + jtsp + tsp_doc
> 
> Eric
> 
> Le lundi 28 février 2005 à 08:12 +0100, address@hidden a
> écrit :
> > 
> > Pour swing vs ligne de commande personnellement je dirais
> > ligne de commande + IHM swing activable optionnellement...
> > par la ligne de commande :))
> > 
> > Ce qui peut être intéressant dans l'IHM c'est les
> > noms de fichiers, URL provider(s) etc... mais également
> > la taille actualisée du fichier généré.
> > 
> > Si tu peux penser dès la conceptions à un writer
> > multi-provider c'est un plus forcément :))
> > 
> > Sinon je vais essayer de m'exciter un peu pour le format
> > XML pour les consumers, mais je peux rien promettre avant avril.
> > 
> > En fait ce qui est "un peu" pénible c'estd'avoir
> > une arborescence globale qui ne permette pas "simplement"
> > de faire un checkout de certains modules séparemment.
> > 
> > En ce qui concerne jtsp, vu que maintenant c'est compile avec ant
> > je préfèrerais:
> > 
> > 1) créer un
> >     1 module jcore de haut niveau
> >     1 module de haut niveau par consumer/provider tsp
> >               jstdout
> >               jsynoptic-plugins
> >               jcdfwriter
> >     1 module chapeau (alias CVS) qui regroupe tou ce beau monde
> >       au bon endroit
> >               jtsp
> > 
> > J'appelle module de haut niveau un module sur lequel on
> > peut faire
> >     cvs co <monmodule>
> > 
> > Un module alias du genre
> >     jtsp  jcore jstdout jsynoptic-plugins jcdfwriter
> > 
> > ce qui fait que quand on fait
> >     cvs co jtsp
> > 
> > on se retrouve avec une arbo propre:
> > 
> >     jtsp/tsp/core/...
> >     jtsp/tsp/consumer/jstdout
> >     jtsp/tsp/consumer/jsynoptic-plugin
> >     jtsp/tsp/consumer/jcdfwriter
> > 
> > etc...
> > 
> > Tout cela est faisable mais pour créer des modules
> > CVS il faut demander aux gestionnaires Savannah car les fichiers
> > du CVSROOT (celui de tsp s'entend) ne nous est PAS accessible
> > en écriture.
> > Par contre on peut soumettre notre fichier module qu'ils 
> controleront
> > et installeront.
> > 
> > A noter qu'on pourrait inclure jstdout dans jcore histoire
> > que si on fait un checkout de jcore on ait au moins 1 consumer.
> > 
> > Ca fait aussi que après ça si on veut jtsp + tsp C ben
> > faudra faire 2 checkout à moins de créer un alias
> > 
> > tsp_all = tsp_all/tsp tsp_all/jtsp
> > 
> > Personnellement je pense qu'on peut faire le test des modules
> > CVS avec la partie java car c'est simple et au passage cela 
> permettra
> > de remettre les jstdout et autre jsynoptic à leur place.
> > L'option ultime pour la partie java serait de créer un unique
> > module de haut niveau: jtsp  qui regroupe tout, mais personnellement
> > ça j'aimerais éviter.
> > 
> > Votre avis?
> > 
> > PS: sinon je suis tout à fait d'accord avec la remarque
> >     de stéphane sur le nommage jcdfwriter devra être ancré
> >     ou ill faut
> > 
> >     jcdfwriter/tsp/consumer/jcdfwriter
> > 
> > si il est pris séparemment et:
> > 
> >     jtsp/tsp/consumer/jcdfwriter
> > 
> > sinon.
> > 
> > Je salue la vivacité de notre Caribou :))
> > A+
> > Eric
> > 
> > -------- Message d'origine--------
> > De:     address@hidden de la
> > part de Stephane Galles
> > Date:   lun. 28/02/2005 07:33
> > À:      tsp-devel
> > Cc:    
> > Objet:  [Tsp-devel] Java : TSP-CDF-Writer
> > Bonjour, bonjour,
> > 
> > Je suis sur le point de commencer un petit Consumer TSP en Java
> > pour écrire des fichiers CDF, et je me demandais où je devais le
> > placer
> > dans l'arbo TSP ?
> > 
> > J'avais pensé à src/consumers/jcdfwriter, mais les 
> premières réactions
> > semblent me dire que ce n'est pas la bonne place... Eric?
> > 
> > Autre question : est ce qu'on veut que notre writer ait une 
> interface
> > en
> > swing ou
> > simplement en ligne de commande ?
> > 
> > Sinon, l'API du CDF en Java a l'air vraiment trés bien, mais j'ai eu
> > une
> > petite surprise :
> > ce n'est pas du Java pur, ce sont des appels JNI à la lib CDF native
> > de
> > la plateforme.
> > C'est pas grave, c'est sans doute mieux pour les perf et 
> tant pis pour
> > la portabilité...
> > 
> > 
> > En parlant d'emplacement dans l'arbo, une petite remarque 
> un peu hors
> > contexte que
> > je voulais faire depuis longtemps :
> > Les deux projets jstdout et jsynoptic ne suivent pas une 
> arborescence
> > standard, et c'est
> > trés pénible avec les IDE qui ne comprennent plus ce qui se 
> passe. Il
> > aurait fallu que les
> > répertoires où sont placés les sources suivent le noms des packages.
> > Hors, pour jstdout
> > il manque tsp/consumer et pour jsynoptic il manque
> > tsp/consumer/jsynoptic (voire par
> > exemple le projet jcore qui lui a une bonne arbo). Simple 
> remarque en
> > passant, mais
> > si on commence de nouveaux projets Java, il ne faudrait pas 
> reproduire
> > cela IMHO.
> > 
> > Steph
> > 
> > 
> > 
> > _______________________________________________
> > 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
>

important_notice.txt
Description: Text document