drba-devs

[Drba-devs] Point Projet : drba

[Francois P. <fp...@us...>]

Le 24 novembre 2008 21:22, <fab...@cp...> a écrit :
J'attends un point par écrit sur les projets le 17 décembre. Vous aurez à
cette date: fixer un cahier des charges, une préetude technique, la gestion
de votre temps sur la fin du projet, votre organisation et la forme des
délivrables à rendre ainsi que les responsables/rédacteurs


Nous vous invitons à regarder notre espace sourceforge pour y découvrir le
projet *drba* à travers la répartition des taches (
http://sourceforge.net/pm/task.php?group_id=244825&group_project_id=57693&func=browse&set=open&order=end_date),
ainsi que le wiki (http://drba.wiki.sourceforge.net/) qui donne quelques
éléments techniques.


*pré-Etude technique:*

Nous avions deux solutions pour le langage utilisé :

   1. *JAVA* :
   - *Avantages*: beaucoup de bibliothèques disponible, un système de plugin
      existant (osgi, ...) et souvent pré-installé, répandus chez les
      développeurs.
      - *Inconvénients*: aucun système de build compatible (obligation
      d'avoir deux machines virtuelles : une python et une java).

      2. *Python* :
   - *Avantages* : beaucoup de bibliothèques disponible de base (tests
      unitaires, clients/serveurs http => API REST, interprétation de code à la
      volée), utilisation directe de librairie permettant la
compilation de source
      (comme waf).
      - *Inconvénients* : peu répandu sous Windows, peu de connaissance du
      langage dans l'équipe, moins de bibliothèques tierces disponibles.

Nous avons choisis d'utiliser *Python*, notamment grâce à la librairie
dérivée de waf

Afin d'augmenter la qualité du code, nous avons utilisé le patern MVC et
l'inversion de contrôle, par injection de dépendances et l'utilisation du
framework Spring-Python.
Les communications se font par un web service de type REST pour les
ressources (ie : archives zip, ...) et le protocole HESSIAN ou SOAP/WSDL
sera utilisé pour d'autres types de web-services (ie : statistiques
diverses).


*Forme des délivrables :*

Les délivrables sont constitués de deux exécutables, un client drba et un
serveur.
De plus, un exemple de projet Python accompagné d'un tutorial sur
l'utilisation de drba sera fourni.


*Responsables/Rédacteurs :*

Jean de Mauroy et Matthieu Gaillard-Midol sont responsables qualité
(rédacteur et documentation).

[Drba-devs] building a waf plugin for drba (french sorry:)

[fabien c. <ta...@us...>]

Francois, puisque j'avais l'impression que tu avais un peu de mal a avancer,
j'ai faits quelques tests pour toi sur le xmlscripting

Bon pour moi ca marche et j'ai regardé pourquoi...
    En fait le principe est plutôt simple (tout d'abord ca ne marche pas
correctement sans une petite modif : il ne fait que créer le fichier python
et le mettre enémoire mais il 'appelle pas le reste du programme)

    Le fonctionnement de waf est waf appel scripting.prepare qui n'est en
fait qu'une simple recherche du fichier xml dans les différents répertoire
que voit waf (path, le rep courant,rep install etc), une fois trouvé il
prend le fichier est en fait un script python qu'il monte en mémoire (le nom
du module étant donné en paramètre/ tu peux voir la source c'est
Utils.load_module) puis fait des traitements dessus que nous ne toucherons
pas... Le plus simple semble donc de définir ce même module à la main soit
en écrivant dynamiquement le python soit tout simplement en écrivant les
fonctions dans un module qui sera monté par nos soins(init configure and co)
qui récupèrerons les paramètres dans projectProperties...

    Attention tout de même car après le preprare de scripting, le main dans
scripting est appelé et ce dernier regarde les paramètre utilisateur passé a
waf ( en utilisant command dans le module options qui n'est juste qu'un
parser de argv en fait) donc il faudra soir redéfinir le main aussi soit
wrapper le module options et/ou main soit le réécrire
(ce que je ne conseil pas du tout le plus propre serait de faire qque chose
du genre a exécuter après l'import et avant l'appel :

 Options.cmds.append('test')
oldmain = Scripting.main
def main():
    if Options.commands['test']:
        Options.commands['build'] = True
    oldmain()
Scripting.main = main

def shutdown():
    if Options.commands['test']:
        # run scripts, etc
        pass

 comme ça on ne touche pas du tout le code de waf donc pour patcher et
changer de version c'est beaucoup plus simple...)

Donc en gros: il suffit juste de changer scripting.prepar_impl pour qu'il
charge notre nouveau module et scripting.main pour qu'il execute sans se
soucier du argv et c'est dans la poche.

Je ne vois plus aucun problème technique maintenant mais si tu en trouves
n'hésite pas à me contacter

Bon week end