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

[Frederik Deweerdt]

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
> 

-- 
o----------------------------------------------o
| http://open-news.net : l'info alternative    |
| Tech - Sciences - Politique - International  |
o----------------------------------------------o