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