AGRÉGATEUR DE FLUX DE BUGS

Publié par

AGRÉGATEUR DE FLUX DE BUGS

Publié le : jeudi 21 juillet 2011
Lecture(s) : 54
Nombre de pages : 24
Voir plus Voir moins
ROBERT Ariane ROTTENBERG Sam            
Rapport de projet ASR 2009-2010
AGRÉGATEUR DE FLUX DE BUGS  
(L’habit ne fait pas le bug)        Sous la direction d’Olivier Berger     
 
 
SOMMAIRE  
PRÉSENTATION DU PROJET ........................................................................................ 3 I. Étude des agrégateurs et des formats de flux ........................................................... 5 1. Les différents formats de flux ................................................................................ 5 2. Étude des agrégateurs de flux RSS open source.................................................... 6 1. Premier contact ...................................................................................................... 8 2. Les différent es façons d’implémenter notre plug -in ............................................. 8 III. Contact avec l’auteur de RSSOwl  ..........................................................................10 IV. Ajout du plug-in ........................................................................................ 11 ............ V. Difficultés rencontrées .............................................................................................13 1. Projet de recherche ...............................................................................................13 2. La collaboration entre équipes sur un projet .......................................................14 3. Complément .......................................................................................................... 15 VI. Estimation du temps de travail.............................................................................16 CONCLUSION................................................................................................................. 17 ANNEXES. ....................................................................................................................... 19  
 
PRÉSENTATION DU PROJET   Notre projet ASR s'inscrit dans le projet HELIOS (Harmoniser l'Environnement Logiciel et l'Industrialiser avec l'Open Source) coordonné par THALES Service dont le but est « d'augmenter la part de marché de l'open source grâce à des solutions industrialisées, minimiser les risques liés à l'intégration des projets hétérogènes et faciliter l'acceptation des solutions open source » (flyer de présentation du projet 1 ).  
Pour cela, le but premier du consortium est de « fournir un portail de solutions logicielles open source pour l'industrialisation et la gestion du cycle de vie des patrimoines applicatifs »(flyer de présentation du projet).  
Ce projet a de nombreux partenaires parmi lesquels : Alcatel-lucent, l'Institut Télécom, ...  
Nous avons eu pour mission de sélectionner un agrégateur de flux RSS open source et de lui ajouter des fonctionnalités d'affichage de flux notifiant des changements d'état de bugs issus de bug trackers divers sur internet. Nous nous sommes penchés sur le format de flux (RSS 1.0, Atom ...) le plus pertinent pour représenter l'ontologie OSLC-CM d'ores et déjà créée en amont par le projet HELIOS, et de contacter les développeurs du projet open source sélectionné afin que nos apports figurent dans les versions futures.
Tel que nous l’a présenté M. Berger, les bug trackers sur internet émettent des flux de notification lorsqu’un état de b ug est modifié, mais ces flux ont des formats hétérogènes. Nous devions produire un outil qui lise un flux "type" de bug, et l’affiche de façon ergonomique. Ainsi un développeur qui suit plusieurs projets divers pourrait l’utiliser pour repérer directement les bugs de statut plus ou moins critique.
                                                          1 http://dev.artenum.com/projects/helios/public/home_fr
 
À terme, le but de ce projet est que l’ontologie OSLC -CM soit intégrée par les bug trackers dans un futur où un nombre consistant de personnes utiliseraient notre outil.
Pour cela, nous avons procédé par étapes :
 Étudier les différents formats de flux qui existent, permettant de représenter une ontologie   Comparer les agrégateurs de flux open source et en choisir un qui soit à la fois prometteur et utilisé (ou utilisable) par de nombreux utilisateurs.   Contacter les développeurs du projet pour voir notre plug-in intégré dans une prochaine version   Récupérer le code source, l’étudier et comprendre comment y participer pour répondre à nos objectifs  
I.  Étude des agrégateurs et des formats de flux  1.  Les différents formats de flux   Il nous a été demandé dans un premier temps d’étudier les spécifications de RSS 1.0 plus particulièrement mais aussi d’ Atom. En effet, une autre équipe travaillait alors à créer un format uniforme de flux selon l’ontologie OSLC -CM pour les bugs sortants de différents bug trackers. Le flux arrivant sur l’agrégateur sélectionné devait donc , en RSS 1.0, utiliser cette ontologie. Cependant, comme le choix du format n’était pas encore définitif, il nous a été demandé de connaitre aussi le format Atom qui a une assez bonne popularité.
Nous avons d’abord considéré le format RSS 1.0 et effectué une ébauche de ce que pourrait être le schéma représentant un bug. Le schéma était correct sémantiquement parlant mais autant était-il approuvé par un validateur RDF, autant a-t-il été rejeté par un validateur RSS 1.0 : nous avions mis le même "about" pour le bloc <item> que pour le bloc <ChangeRequest>, et en RSS 1.0, on ne peut pas avoir deux fois le même about dans un flux. (annexe 1)
Nous avons fini par créer un format approuvé par le validateur RSS 1.0 en donnant des "about" différents mais en créant dans le bloc <item> une ressource vers le même about que <ChangeRequest>. (annexe 2)
En fin de compte, Atom a eu raison de RSS 1.0 et M. Berger nous a fourni des modèles de flux (annexe 3) tels qu’ils devraient être générés pour que nous puissions nous intéresser à la contribution au projet open source dagrégateur choisi.
 
2.  Étude des agrégateurs de flux RSS open source   L’objectif du projet HELIOS est de rendre l’open source plus accessible en créant des outils "universels". Pour cela, il faut que ces outils soient utilisés par le plus grand nombre , et qu’ils soient de préférence open source aussi . Lagrégateur  de flux auquel nous devions contribuer devait donc répondre à certains critères.
Il devait notamment avoir déjà une certaine popularité, être de préférence multiplateforme et avoir une participation active des développeurs au moment où nous le choisissions. De cette façon, lorsque les utilisateurs auront accès à cet outil, ils l’ utiliseront déjà ou auront envie de l’utiliser .
Le début des recherches n’a pas été très fructueux : nous avons récolté les informations que nous trouvions à partir des simples moteurs de recherche sur Internet en vrac. Heureusement, M. Berger nous a ensuite recommandé d’utiliser Ohloh 2  et Freshmeat 3  qui réunissent des projets open source avec de multiples informations sur le code, la dynamique de la contribution et les participants. 
Nous avons alors créé un tableau (annexe 4) recensant les principaux agrégateurs trouvés à partir de nos recherches, et représentant nos critères de sélection. Nous avons noté chaque agrégateur en fonction de chaque critère pour pouvoir évaluer les projets par moyennes pondérées en donnant plus ou moins de poids aux critères retenus selon leur pertinence.
Et le vainqueur de ce grand concours a été  RSSOwl 4 ! Un agrégateur open source multiplateforme codé principalement en Java ce qui du point de vue des connaissances que nous avions déjà nous arrangeait, et comme nous le
                                                          2 http://www.ohloh.net/ 3 http://freshmeat.net/ 4 http://www.rssowl.org/
découvrions lors de l’étude du code source, cet outil a été assez bien conçu pour
prévoir l’ajout d’extension concernant des formats de flux qui ne sont pas
encore reconnus pour un affichage adapté à leur contenu.
 RSSOwl arrivait premier dans les moyennes d’évaluations que nous avons
effectuées. Si nous n’avions pas jugé important de choisir un agrégateur qui soit
multiplateforme, nous aurions beaucoup plus hésité avant d’arrêter not re choix.
Liferea est par exemple un agrégateur qui tourne sur Linux exclusivement et
dont les caractéristiques répondent très bien aux critères d’évaluation.  
II.  Étude du code source de RSSOwl  1.  Premier contact   Nous avons utilisé Eclipse pour récupérer le code du projet sous SVN. Une fois le projet installé, avec l’ensemble des classes et packages sous les yeux, il nous a alors fallu trouver la partie qui nous intéressait. Cette étape nous a demandé un peu de temps. Nous avons donc parcouru les classes de fonction en fonction pendant quelques heures avant de trouver celle qui nous intéressait.
Le code étant comme l’indiquaient Ohloh et Freshmeat assez bien commenté, nous avons alors rapidement constaté qu’une balise non reconnue par le code de la classe AtomInterpreter pouvait être traitée par une autre classe dont l’existence devait être signifiée dans le fichier "plugin.xml" dont la structure est décrite dans les fichiers "NamespaceHandler.exsd" ou "ElementHaldler.exsd".
 2.  Les différentes façons d’implémente r notre plug-in  En effet, il existe deux façons d’ajouter une extension : soit en créant une classe dans le même package que AtomInterpreter qui s’occupe du traitement de namespace (il existe par exemple une fonction DublinCoreNamespaceHandler), soit en créant une classe toujours dans le même package qui traite une balise Atom en remplaçant la partie de la méthode de AtomInterpreter créée pour s’en charger.
 
 Notre exemple de flux de bug n’utilisant pas le na mespace OSLC-CM, la solution la plus logique se rait de créer une classe gérant l’affichage du contenu de <content>. Cette dernière méthode nous gênait car nous préférions éviter de remplacer une partie de code déjà existante par une méthode que nous aurions faite pour afficher les informations sur le bug à l’ouverture du flux. N ous nous sommes donc renseignés pour savoir s’il n’était pas plutôt possible de modifier légèrement le flux de bug avec un modèle que nous avons créé. Mais comme la transformation du flux émis par les bug trackers en flux-type Atom dont nous nous servons est gérée par une équipe indépendante, il nous restait alors deux possibilités. 
La première : ajouter une classe traitant le contenu de la balise <content> en ajoutant la possibilité pour cette dernière d’avoir pour type "applic ation/xml". La méthode qui s’occupe de l’affichage du contenu de <content> dans le code ne gère alors jusqu’à présent que les types "xhtml" et "application/xhtml+xml".  
Le principal désavantage qui nous a rebuté longuement est que, remplaçant cette dernière portion de méthode, il nous fallait "copier-coller" son contenu dans notre classe pour continuer à traiter les cas gérés avant notre intervention.
La deuxième : ajouter un filtre dans la fonction existante pour notre flux dans la classe AtomInterpreter. Cela nous dérangeait aussi dans la mesure où on n’utiliserait alors pas l’implémentation qui prévoit l’ajout de fonctionnalités  pour traiter les nouveaux cas de flux, et on participerait alors directement à la méthode créée par le programmateur principal de RSSOwl.
Il devint alors imminent de contacter ce dernier pour lui communiquer nos projets et lui demander son avis sur notre apport.
 
  
 III.  Contact avec l’auteur de RSSOwl   
RSSOwl est très principalement codé par une seule personne : Benjamin Pasero. Nous avons mis beaucoup (trop) de temps à le contacter car nous voulions être sûrs (trop ?) de ce que nous allions lui dire et lui demander comme conseils pour contribuer. Nous souhaitions vivement que ce dernier accepte non seulement d’intégrer notre plug -in à une version ultérieure de RSSOwl, mais aussi de nous conseiller sur la façon dont il préférait que nous l’ implémentions. 
Tout cela en lui annonçant qu’il était impossible pour nous d’utili ser les fonctionnalités qu’il avait prévu es permettant à qui le voudrait de configurer le traitement d’un flux non reconnu par son agrégateur.  
 Une autre raison est que, bien que très enthousiastes à l’idée de laisser notre trace dans le vaste monde de l’open source, nous étions dans un premier temps un peu timides.
Nous avons donc pris notre courage à deux mains à un moment où nous n’avions plus tellement le choix  : il ne nous restait plus qu’à programmer notr e plug-in et nous étions coincés sur la façon de le faire . Il s’est montré très cordial  dans sa première réponse et nous avons répondu en entrant plus dans les détails pour qu’il comprenne bien où était notre problème.  
Malheureusement, nous attendons toujours une réponse à ce dernier mail.
 IV.  Ajout du plug-in  Comme nous n’avons pas obtenu de réponse de la part d e Benjamin Pasero assez en avance, nous avons décidé de créer au moins les fonctions permettant de mettre en page notre flux de bug.
 
Nous avons créé une classe qui remplace la partie de la méthode getContent() concernée de la classe AtomInterpreter. Nous a vons d’abord commencé par déléguer le traitement de l’affichage à la cla sse DublinCoreNamespaceHandler pour vérifier l’affichage prévu par le code initial. Puis, nous avons décidé de filtrer chaque balise dublincore de <content> pour les afficher de façon plus ergonomique. 
Notre affichage comprend :
 les titres de <entry> et <content> concaténés comme titre du flux  un titre en gras correspondant à chaque balise de <content> et le texte  qu’elle contient à la suite   un lien permettant de contacter l’auteur de la modification de l’état du bug  la date d’émission de la notification de changement d’état  
Soyez le premier à déposer un commentaire !

17/1000 caractères maximum.