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

[Eric NOULARD]

Nous avons donc une majorité pour la simplicité.

Je crée ce jour 2 modules de haut niveaux:

jtsp
tsp_docs

ces 2 modules ne contiennent qu'un README.
J'attends l'archive de Stéphane pour peupler le répertoire jtsp
avec autre chose qu'un README, y'a pas de presse 
je fais ça de suite pour pouvoir, en attendant,
demander aux savannah-hackers les opérations que je n'ai
pas le droit de faire:

1) déplacer les modules de haut niveaux:
   tsp_whitepaper
   tsp_bbguide 

   dans tsp_docs

2) Installer un fichier CVSROOT/modules qui definisse
   le module 'tsp_all' contenant tsp, jtsp, tsp_docs.

Wouala.
Eric

Le mercredi 02 mars 2005 à 20:04 +0100, Frederik Deweerdt a écrit :
> Salut, 
> Désolé pour le retard à l'allumage... j'opterai aussi pour la solution 
> simplifiée.
> Ca parait le plus simple a mettre en oeuvre, plus répandu comme technique donc
> plus rapide à prendre en main :)
> A+
> Fred
> 
> Le Mon, Feb 28, 2005 at 08:46:05PM -0500, Stephane Galles écrivit:
> > 
> > Hello Eric,
> > 
> > Bravo pour les fichiers de test, mais en ce qui me concerne j'opte
> > pour la solution "simple" (soit uniquement tsp_all == tout tsp == tsp + 
> > jtsp + tsp_doc)
> > 
> > Sachant qu'on a tous des connexions internet rapides, je ne suis pas sur 
> > de voir ce qu'un
> > découpage aussi fin amène. Mais il y a peu être un cas d'utilisation que 
> > je ne voit pas.
> > 
> > En plus comme tu l'a dit toi même, cela simplifie les Makefile/Ant, et 
> > en pouvant
> > créer de maniére autonomes de nouveaux projets, on gagne en agilité (mot 
> > à la mode)
> > 
> > Et puis si on prend l'exemple des projets CDF, c'est à peu près ce qu'il 
> > font aussi :
> > ils ont un tar.gz C, un tar.gz Java, et de la doc. Cela ne doit pas être 
> > mauvais donc.
> > 
> > 
> > Eric NOULARD wrote:
> > 
> > >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-deve
> > >>
> > >l
> > > 
> > >
> > 
> > 
> > 
> > _______________________________________________
> > Tsp-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/tsp-devel
> > 
>