interfaçage du bugtracker debian pour mylyn

Transcription

Semestre 2008/2009 – TELECOM SudParis
PFE
INTERFAÇAGE DU BUGTRACKER DEBIAN
POUR MYLYN
Projet de Fin d’Etudes encadré par M. BAC et M. BERGER
Jing Hu
Xavier Martin
Carole Riffault
Interfaçage du bugtracker Debian pour Mylyn – Rapport
Introduction
Il est souvent établi que la réalisation d’un logiciel, qu’il soit à des fins commerciales ou
communautaires, est constituée à 60% de maintenance. Les environnements de développement
intégré (IDE) ont bien compris l’importance d’outils de détection de bugs et en intègrent
généralement dans leur solution.
Parmi ces IDE, Eclipse1, initié par IBM et maintenue par la Fondation Eclipse, est l’une des
plateformes de développement les plus utilisées actuellement. Bien implantée dans le monde de
l’Open Source, elle a su développer autour d’elle une communauté active de développeurs. Sa
politique stricte de méthodes d’ajout de fonctionnalités via des plugins architecturés selon les
recommandations de la norme OSGI2 permet des développements robustes.
Un système de suivi de bugs est une application informatique qui permet de soumettre des
défauts de fonctionnement rencontrés dans un logiciel et d’assurer un suivi de ceux-ci.
Mylyn un des sous-systèmes d’Eclipse qui permet au programmeur de gagner en efficacité ; il
lui donne la possibilité d’accéder à un système de suivi de bugs et d’éditer son contenu, sans quitter
l’environnement de développement. Il joue le rôle d’assistant du programmeur.
Dans ce rapport, nous verrons tout d’abord les objectifs du projet qui nous a été confié puis la
manière dont nous avons choisi de le traiter. Seront ensuite détaillés le fonctionnement du système
de suivi de bugs de Debian et de Mylyn, et comment créer un connecteur pour les faire
communiquer entre eux. Une partie abordera les difficultés rencontrées durant ce projet. Enfin, la
liste de la documentation créée et mise à disposition sera détaillée.
1
http://www.eclipse.org/
2
http://www.osgi.org/
2
Sommaire
Introduction ................................................................................................................................. 2
Sommaire .................................................................................................................................... 3
1.
2.
3.
4.
5.
Présentation du projet....................................................................................................... 4
1.1.
Contexte .................................................................................................................... 4
1.2.
Enoncé....................................................................................................................... 5
1.3.
Objectifs précis.......................................................................................................... 5
Mise en place du projet ..................................................................................................... 6
2.1.
Organisation et outils................................................................................................ 6
2.2.
Les connecteurs existants ......................................................................................... 7
2.3.
Architecture de communication schématisée .......................................................... 7
2.4.
Analyser le BTS Debian et Mylyn .............................................................................. 8
Le BTS Debian .................................................................................................................... 9
3.1.
Qu’est-ce que c’est ?................................................................................................. 9
3.2.
Son fonctionnement ................................................................................................. 9
Mylyn ............................................................................................................................... 11
4.1.
L’articulation du code ............................................................................................. 12
4.2.
La gestion des tâches .............................................................................................. 13
4.3.
La communication................................................................................................... 18
Bilan du projet ................................................................................................................. 19
5.1.
Les difficultés rencontrées ...................................................................................... 19
5.2.
Justification de la révision des objectifs ................................................................. 19
5.3.
La documentation laissée à disposition .................................................................. 19
Conclusion ................................................................................................................................. 21
Annexes ..................................................................................................................................... 22
Cas d'utilisation : le connecteur Mantis ................................................................................ 22
Les deux attributs majeurs du bug sous Debbug : l'étiquette et la sévérité ........................ 24
3
1. Présentation du projet
1.1. Contexte
Pour aider à la gestion et surtout à la maintenance des projets, différents systèmes de suivi de
bugs ont été mis en place.
Un bug tracking system (BTS) ou système de suivi de bogues est une application
informatique qui permet d'aider développeurs et utilisateurs à améliorer la qualité d'un logiciel. Les
utilisateurs soumettent les bogues (défauts de fonctionnement) rencontrés dans le logiciel. Les
développeurs sont alors toujours au fait des problèmes rencontrés.3
Dans le contexte du libre en général, on parle de communauté Open Source et de
communauté du logiciel libre. La différence est principalement relevée par la Fondation pour le
Logiciel Libre (Free Software Foundation – FSF4). Dans ce rapport, nous ne ferons aucune distinction
entre ces deux communautés5.
Les développeurs et utilisateurs de logiciels libres réalisent ou utilisent des outils fondés sur
un mode de production reposant sur la collaboration, l’entraide, le partage, la mutualisation6. A ce
titre, le projet dont il est question dans ce document est pleinement en lien avec cette communauté.
Les applications qui seront étudiées font toutes partie intégrante de l’Open Source. Le projet
présente un lien avec l’environnement de développement intégré Eclipse. A celui-ci s’ajoute en
particulier un de ses sous-systèmes, Mylyn, qui permet d’accéder à un système de suivi de bugs et
d’éditer son contenu, sans quitter l’environnement de développement Eclipse. Enfin, sera examiné le
système de suivi de bugs de Debian, Debbugs7. Debian est un système d’exploitation reposant sur les
principes du logiciel libre. Il est réputé pour sa fiabilité et son mode d’unification d’éléments
développés indépendamment les uns des autres, modulables en fonction des besoins et appelés
« paquets ».
Enfin, les informations qui seront fournies à la fin de ce projet pourront directement
alimenter les travaux des encadrants dans le cadre du projet Helios8. Ce projet, auquel participent de
grands groupes et des universités, consiste à réaliser un portail Open Source basé sur des logiciels
libres existants et dédié à la gestion du cycle de vie des logiciels d'un système de bout en bout. En
particulier, les chercheurs de TELECOM & Management SudParis travaillent sur la traçabilité des
anomalies entre plateformes de développement. Dans le cadre de ce projet, ils cherchent à
développer des outils de synchronisation entre différents types de systèmes de gestion de bugs, de
3
Source : http://fr.wikipedia.org/wiki/Bug_tracking_system
4
http://www.fsf.org/
5
Une brève description des différences entre communauté open source et du logiciel libre :
http://fr.wikipedia.org/wiki/Communaut%C3%A9_du_logiciel_libre
6
http://fr.wikipedia.org/wiki/Logiciel_libre
7
http://packages.debian.org/unstable/misc/debbugs
http://en.wikipedia.org/wiki/Debian_bug_tracking_system
8
http://www.helios-platform.org/
4
manière à ce que chaque bug détecté soit à coup sûr communiqué à toutes les équipes qui
pourraient en avoir besoin.
1.2. Enoncé
Ci-dessous, l’énoncé du sujet tel qu’il nous a été fourni lors du choix des projets.
Mylyn est le nom d'un sous-système d'Eclipse s'occupant de la gestion des tâches
(http://www.eclipse.org/mylyn/).
Le nom du projet est inspiré du mot anglais myelin (myéline), nom de l'isolant gainant
les axones pour éviter la dispersion de l'influx nerveux. Le projet veut en effet isoler le
programmeur de toutes les tâches de routine pouvant le distraire de sa fonction première, qui
est de coder en restant concentré sur son code.
Mylin joue le rôle d'assistant du programmeur, intégrant dans Eclipse des modes
d'édition lisibles (RTF) de dépôts comme Bugzilla, Trac et JIRA. -http://fr.wikipedia.org/wiki/Mylyn
L'objectif du projet sera d'intégrer une interface vers le bug-tracker du projet Debian
(http://bugs.debian.org/) dans Mylyn.
Le but d'une telle interface est d'offrir une alternative pour les contributeurs du projet
Debian dans les tâches d'assurance qualité nécessitant une forte interaction avec le contenu
du bug-tracker.
Si possible, on cherchera à contribuer à la dynamique logiciel libre du projet Mylyn en
proposant des éléments libres diffusables et réutilisables.
1.3. Objectifs précis
Le but étant de réaliser un connecteur entre Mylyn et Debbugs, le bugtracker de Debian,
notre projet s’est principalement axé sur l’analyse du fonctionnement de ces deux systèmes. Pour ce
faire, nous avons étudié l’architecture de Mylyn, puis analysé les connecteurs existants. En
examinant l'architecture de Debbugs et en s'inspirant des divers connecteurs, nous avons recherché
la façon dont il était possible de les faire communiquer.
Il était indispensable de bien comprendre comment chacun de ces éléments s’articulait afin
de pouvoir les prendre en main au mieux. Les premiers efforts de recherche visaient principalement
à appréhender le fonctionnement global des projets open source en testant leur utilisation puis en
commençant à analyser l’architecture d’un projet précis (Mylyn, Debbugs ou un connecteur).
L’essentiel de l’effort devait ensuite se porter sur de la documentation permettant d’expliquer
l’architecture des systèmes à analyser. Les informations qu’il était nécessaire d’analyser pouvaient
être récupérées via les différentes mailing-lists, les wikis des communautés, ou bien encore, en
explorant directement les codes source.
5
2. Mise en place du projet
2.1. Organisation et outils
Afin d’être le plus efficace possible, certaines bonnes pratiques ont rapidement été mises en
place. Le projet pfe_mylyn a été créé sur la plateforme Picoforge9 afin de pouvoir bénéficier des
différents outils mis à disposition, en particulier : une mailing-list, un wiki, un svn.
Ainsi, les échanges sur le projet pour discuter de points précis ou pour convenir des
prochaines réunions pouvaient être réalisés directement en envoyant un mail à
[email protected]. Cette liste permettait de joindre les deux encadrants, les trois
étudiants et Valentin Vlasceanu, doctorant participant également au projet Helios WP3.
Le wiki a été pris en main afin de pouvoir centraliser les découvertes importantes. L’édition
nécessitait de prendre connaissance des normes de formatage du texte.
L’habitude a été prise d’effectuer environ une réunion d’avancement par semaine et d’en
ajouter le compte-rendu sur le wiki. Ceux-ci sont disponibles à cette adresse : https://picoforge.intevry.fr/cgi-bin/twiki/view/Pfe_mylyn/Private/AllReports.
Les transparents utilisés pour certaines des réunions ont été stockés sur le svn du projet, de
même pour les documents que nous avons jugés importants.
Pour récolter les informations utiles à l’analyse des différents systèmes, nous nous sommes
inscrits à la liste de diffusion spécifique aux intégrateurs de Mylyn afin d’y discuter de certains points
de fonctionnement de cette application.
Pour générer des schémas de tout type, et en particulier des diagrammes UML, l’application
en ligne Gliffy10 a été utilisée. Elle permet le travail collaboratif en donnant la possibilité de créer ses
propres figures et ensuite de les partager en lecture ou en modification. Un historique des
enregistrements étant conservé, on peut facilement faire du versioning des schémas.
Par ailleurs, le code source de Mylyn étant composé de plus d’une centaine de classes et
d’une documentation et de commentaires de code quasi nuls, son analyse nécessitait d’utiliser des
outils pour mieux organiser les recherches. Ainsi, les logiciels Sorcerer11 et Doxygen12 ont été étudiés
pour voir lequel pouvait répondre le mieux à nos attentes. Leurs fonctionnalités ont été survolées et
les deux outils semblent offrir sensiblement les mêmes fonctionnalités :
 liens vers les sous-classes et super-classes
 liens vers les méthodes surchargeant la méthode courante
 liens vers les méthodes surchargées par la méthode courante
 liens vers les déclarations des variables, méthodes, types, packages, etc.
9
http://picoforge.int-evry.fr/
10
http://www.gliffy.com/
11
https://sorcerer.dev.java.net/
12
http://www.doxygen.org/
6
Le gros avantage de Doxygen est de proposer une génération automatique de graphes de
dépendances, de schémas d'héritage et de diagrammes de collaboration, ceci à l'aide de l'outil
Graphviz13.
2.2. Les connecteurs existants
Mylyn possède des connecteurs avec en tout 3 systèmes de gestion de bogues, considéré
comme des systèmes de dépôts de tâches étant donné qu'on se place du point de vue du
développeur. Ces systèmes sont Bugzilla, JIRA et Trac.
Bugzilla est un logiciel de suivi de bug développé par la fondation Mozilla. Projet au départ
créé par Netscape pour faciliter le développement de Netscape Communicator, son code a été rendu
accessible en 1998 dans le cadre du projet Mozilla. C'est aujourd'hui un projet Open Source, son code
est en Perl et nécessite plusieurs outils web pour fonctionner correctement : un système de gestion
de bases de données, un serveur web, un serveur smtp.
JIRA est un système de suivi de bug et de gestion de projet développé par la société Atlassian
Software Systems. Bien que mis à disposition de nombreux projets gratuitement, ce logiciel n'est
libre d'accès que sous certaines conditions fixées. Les projets Open Source y ont notamment accès,
c'est pourquoi des projets tel que Fedora et Jboss y font appel. Son code Source est écrit dans le
langage Java.
Trac est un système de gestion de projet par Internet qui comprend entre autre un système
de suivi de bugs. Il a été développé dans le langage Python par la société Edgewall Sotfware.
Longtemps sous licence GNU GPL, il est aujourd'hui distribué sous licence BSD. Son interface Web a
utilisé le moteur ClearSilver dans un premier temps, mais c'est le moteur Genshi qui est aujourd'hui
utilisé.
Les BTS précédemment cités sont ceux qui possèdent une interface réellement implémentée
sous Mylyn, chacune d'entre elles ayant son propre fonctionnement. Il est aussi possible, via un
connecteur web générique, d'accéder à la liste des bugs des systèmes de dépôts suivants : Google
Code Hosting, IssueZilla, GForge, SourceForge, Mantis, ChangeLogic, OTRS, phpBB, vBulletin. On ne
s'intéressera cependant pas à ce type de connecteurs, étant donné que notre préoccupation est de
créer un connecteur réellement adapté au fonctionnement de Debbugs et non de simplement
extraire la liste de bug à partir d'un site Web.
2.3. Architecture de communication schématisée
Une analyse rapide du fonctionnement de Debbugs permet de voir que le logiciel
communique avec la base de données de 3 manières : en utilisant le système de communication par
mails, par interface web (en utilisant le langage CGI) et par interface SOAP.
Du côté de Mylyn des connecteurs sont implémentés et utilisés pour communiquer avec les 3
BTS précédemment cités. Ils peuvent entre autre communiquer avec les bases de données de ces
BTS par le protocole SOAP, ou en utilisant des Web Templates pour se connecter en HTML
A partir de cette analyse, la communication entre Mylyn et Debbugs semble réalisable via 2
technologies différentes, soit en HTML ce qui permet un d'utiliser un protocole simple et léger, soit
en SOAP ce qui permet d'utiliser de nombreux langages pour envisager le codage à réaliser.
On peut résumer la démarche envisagée par le schéma suivant :
13
http://www.graphviz.org/
7
2.4. Analyser le BTS Debian et Mylyn
Pour mettre en place cette architecture, il sera d'abord important d'analyse le code source
des 2 logiciels, notamment pour décrypter leurs méthodes de communication.
Dans le cas de Debbugs, une analyse préliminaire de la manière de communiquer avec la base
de données via le système d'envoi de mails pourrait être intéressante pour comprendre comment est
structuré un bug selon les normes de Debian, quel sont les informations qui lui sont associées, qui
peut avoir accès à sa modification. Il sera ensuite nécessaire d'entrer dans le code source,
principalement écrit en langage Perl, pour approfondir les informations obtenues lors de la
précédente étude et pour comprendre comment utiliser les systèmes de communication mis à
disposition par le logiciel, notamment l'interface SOAP qui semble être la plus intéressante pour
notre projet.
En ce qui concerne Mylyn, il sera d'abord important de comprendre comment fonctionne
Mylyn, en quoi cet outil facilite le travail des développeurs avant d'entrer dans la structure de ce sous
logiciel et dans son code source pour comprendre notamment comment est considéré une tache,
quelle sont ses caractéristiques, comment Mylyn fait la correspondance entre ces taches et les bugs
récupérés dans les différents BTS, et comment se fait la communication avec ces derniers.
8
3. Le BTS Debian
Un Bug Tracking System (BTS)14 est un logiciel permettant d'améliorer un logiciel par une
consultation structurée par les développeurs des différents bugs constatés par les utilisateurs. Ces
systèmes de signalement d'erreurs peuvent souvent être réutilisés pour le suivi de projets non
informatiques. Certains BTS sont utilisés pour le développement de logiciels Open Source,
permettant à n'importe quel utilisateur de signaler un bug, alors que d'autres sont réservés au
fonctionnement interne de l'entreprise. Le BTS Debian correspond au premier cas.
3.1. Qu’est-ce que c’est ?
Le logiciel Debbugs a été développé principalement par Ian Jackson. Le responsable de son
évolution est aujourd'hui Don Amstrong. Il s'agit d'un ensemble de scripts qui éditent la base de
données des mails via l'envoi de mails, utilisant le système précédemment expliqué, mais aussi
l'interface web via des scripts CGI. Le code source est écrit en Perl pour sa plus grande partie. Il est
distribué sous licence GPL, et est totalement Open Source.
Le logiciel est téléchargeable sur le site de Debian. Sa dernière version stable est la 2.4.1, qui
se trouve entre autres dans la version 5.0 de Debian (lenny). Le code se source à l'adresse
http://bugs.debian.org/debbugs-source/mainline/.
En étudiant notamment le fichier Debbugs/bugs.pm, on obtient une liste plus complète des
attributs du bug dans le logiciel :










id : numéro d'identification du bug
package : nom du package binaire affecté
src : nom du package source affecté
maint : adresse du responsable
submitter : adresse de la personne ayant soumis le bug
severity : sévérité
status : état du bug
tag : étiquette
owner : propriétaire du bug (son adresse)
correspondent : adresse d'une personne ayant envoyé un mail au log
3.2. Son fonctionnement
3.2.1. Le système de mails
La communication par mail au sujet des bugs se divise en 3 catégories : soumettre un bug,
consulter la documentation liée à ce bug et manipuler ce bug.
Soumettre un bug est une méthode simple, qui permet de s'affranchir du logiciel reportbug. Il
suffit pour signaler un bug d'envoyer un mail à l'adresse [email protected] en précisant le
paquet concerné par ce bug et sa version dans un pseudo entête situé dans le début du corps du
mail. Il est aussi possible de définir la sévérité du bug et d'y ajouter des étiquettes (parfois liées à
l'utilisateur) dans ces pseudos entêtes.
Le système de requête consiste à envoyer un mail à l'adresse [email protected]. Le
sujet de ce message ne sera pas pris en compte, et le corps doit uniquement être constitué de
14
http://fr.wikipedia.org/wiki/Bug_tracking_system
9
commandes précises permettant de demander des informations liées aux bugs (rapport,
responsables, bugs récemment modifiés, ...). La réponse n'est renvoyés par le serveur que si le
message est correctement formaté et si le nombre de requête n'est pas excessif.
Il est enfin possible de manipuler un bug en envoyant un mail à l'adresse
[email protected]. Le système est le même que pour les requêtes (commandes sans tenir
compte de l'entête) mais dispose de commandes supplémentaires. Ces commandes permettent de
modifier l'état d'un bug, notamment de déterminer s'il est présent ou résolu dans une version
précise du paquet, de modifier son propriétaire, son responsable, sa sévérité, ses étiquettes,
d'archiver ou de désarchiver un bug.
A partir de cette étude, on peut notamment extraire 2 attributs importants : la sévérité, et les
étiquettes. Les différentes valeurs que peuvent prendre ces attributs sont signalées en annexe. Le
bug possède aussi un responsable, un propriétaire, un numéro d'identification, et il est associé à un
paquet. Les différentes versions de ce paquet sont alors classées comme found (le bug est présent)
ou fixed (le bug est résolu).
3.2.2. L'interface SOAP
Les dernières versions de Debbugs comprennent une autre manière que le web et l'envoi de
mail pour communiquer avec la base de données : une interface SOAP.
SOAP (Simple Object Access Protocol) est un processus RPC permettant la transmission de
messages entre objets distants, ce qui signifie concrètement qu'il permet à un objet d'utiliser une
méthode qui ne lui est théoriquement pas accessible car présente sur un autre serveur. Ce processus
est basé sur XML et à l'avantage d'être indépendant du langage utilisé.
Dans le cas qui nous intéresse, les développeurs ont mis en place une interface qui permet
d'appeler les méthodes suivantes :
. get_status(bugnumber [, bugnumber]*)
Cette fonction permet d'obtenir l'état d'une liste de bugs à partir de leurs numéros
d'identification
. get_bugs(key, value[, key, value]*)
Cette fonction retourne un bug (et ses attributs) à partir d'une clé spécifique, ou d'un liste de
ces clés.
Clés utilisables : package (binaire), personne ayant soumis le bug, responsable, package
(source), gravité, status, tag, propriétaire, liste de bugs (identifiants)
. get_usertag(email [, tag]*)
Cette fonction permet d'obtenir les bugs marqués par l'adresse email entrée en paramètre.
. get_bug_log(bugnumber)
Cette fonction renvoie le log complet d'un bug, dans une structure prédéfinie semblable à
celle d'une page HTML
. newest_bugs(amount)
Cette fonction retourne une liste des bugs les plus récents (fixée par défaut à 5)
L'interface est donc assez intéressante car elle permettrait de communiquer avec Debbugs
via un protocole utilisable par de nombreux langages (notamment Java et Php). Mais elle ne propose
que des méthodes de consultation de la base de données et le control n'est pas pris en compte, il
serait donc nécessaire d'utiliser l'interface mail ou de créer notre propre code en perl si nous
souhaitons permettre à l'utilisateur de modifier lui même les bugs.
10
4. Mylyn
Mylyn est le nom d'un sous-système d'Eclipse s'occupant de la gestion des tâches. [Il]
joue le rôle d'assistant du programmeur, intégrant dans Eclipse des modes d'édition lisibles de
dépôts comme Bugzilla, Trac et JIRA.
Une fois ces tâches intégrées, Mylyn scrute le profil d'activité du programmeur pour
identifier à tout moment la tâche en cours et afficher les informations pertinentes relatives à
cette tâche en fonction du contexte en commandant l'interface graphique d'Eclipse.
Son but est de réduire le temps consacré par le programmeur à :
 La recherche d'information
 L'exploration des textes de la source et de l'aide
15
 La navigation dans les fichiers.
Le but final de l'étude est de relier entre eux les différents BTS pour faciliter le travail des
développeurs en coordonnant les informations présentes parmi ces logiciels. Par exemple, un bug
peut à la fois être signalé sur le navigateur Firefox et sur la distribution Debian sur laquelle ce
navigateur fonctionne.
La coordination via Mylyn de ces BTS pourrait amener à une synchronisation des différents
bugs suivants leurs caractéristiques, pour ensuite les relier et standardiser selon un modèle RDF. On
pourrait ainsi créer une base de données consultable via le langage SPARQL et ne plus avoir à fouiller
dans différents BTS pour résoudre un bug qui affecte plusieurs logiciels mais qui n'est présent que
dans un seul.
Bug-tracker
de Debian
Bug-tracker
de Bugzilla
Bug-tracker
de Jira
Synchronisation
Et standalisation en
RDF (BOM)
SPARQL
15
http://fr.wikipedia.org/wiki/Mylyn
11
Bug-tracker
de ...
4.1. L’articulation du code
4.1.1. Bridges
Mylyn s'appuie sur des bridges pour intégrer le modèle de contexte avec la structure et les
caractéristiques de l'interface utilisateur des outils. Il y a deux sortes de bridges :
 Bridge de structure : fait correspondre les éléments spécifiques à chaque domaine et les
relations avec les handleIdentifiers qui sont plus génériques et compris par le
modèle de structure ;
 L’extension
se
nomme
structureBridge
et
est
définie
dans
org.eclipse.mylyn.context.core.bridges.
 Bridge d'interface utilisateur : intègre des fonctionnalités de Mylyn, comme le bouton
« Sélectionner la tâche active », avec des éditeurs et des vues.
 L’extension
uiBridge
est
définie
dans
org.eclipse.mylyn.context.ui.bridges.
Les
utilitaires
de
surveillance
de
l'interface
utilisateur
du
workbench
(org.eclipse.mylyn.monitor) traduisent l’interaction avec des éléments spécifiques à chaque
domaine (par exemple, les méthodes Java) en un historique d’interactions. Le gestionnaire de
contexte (org.eclipse.mylyn.context.core) s'appuie sur un bridge de structure pour créer un
modèle de contexte à partir de ces éléments et des relations qui existent entre eux. Le bridge de
structure est aussi utilisé par les utilitaires d'interface utilisateur pour faire correspondre les
éléments affichés (dans les vues et les éditeurs) au modèle de contexte, afin de déterminer leur
classement par intérêt. Ce classement est alors utilisé pour filtrer et replier des éléments dans
l'arborescence.
12
4.1.2. Interface de programmation (API) communes
Les interfaces de programmation communes de Mylyn fournissent des éléments communs
qui sont utilisés par les autres composants de Mylyn. Ils incluent :



Commons Core : Le plug-in org.eclipse.mylyn.commons.core fournit l'interface de
programmation (API) StatusHandler pour traiter des erreurs, ainsi que d'autres classes
d'utilitaires.
Commons Net : Le plug-in org.eclipse.mylyn.commons.net fournit une interface de
programmation pour les connexions Apache de HttpClient, utilisée par les connecteurs
de Mylyn pour se connecter à des services web.
Commons UI : Le plug-in org.eclipse.mylyn.commons.ui fournit des composants
d'interface graphique communs et des extensions du workbench utilisées par d'autres
composants de Mylyn.
4.2. La gestion des tâches
Mylyn ajoute de nouvelles fonctionnalités à Eclipse SDK en permettant un suivi de tâches.
Une tâche dans Mylyn est un travail à accomplir qu'on souhaite se rappeler ou partager avec les
autres, comme un bug, une note personnelle à propos d'une amélioration, etc. Dans le cadre de
notre projet, les tâches de Mylyn sont en fait utilisées pour décrire des bugs, aussi appelés tickets
dans d'autres systèmes de gestion de bugs. Mylyn permet de stocker des tâches localement ou de
travailler avec des tâches stockées dans un ou plusieurs dépôts de tâches, grâce à des connecteurs
adaptés.
Une fois qu'une tâche est intégrée, Mylyn crée et manipule un "contexte de tâche" qui
contient tous les éléments liés à votre tâche. Ceux-ci peuvent inclure des documents consultés, des
méthodes modifiées et des API utilisées. Mylyn utilise le contexte de tâche pour adapter l'interface
utilisateur en se concentrant sur les informations pertinentes, en cachant ce qui n'est pas intéressant
et en trouvant automatiquement les informations qui ont un rapport. Mylyn aide ainsi les
développeurs à améliorer leur productivité en réduisant le temps passé en recherche, défilement et
navigation.
La figure ci-dessous avec les zones numérotées illustre quelques exemples de gestion de
tâche et de contexte :
1. Une liste de tâches avec une tâche active et les rapports de Bugzilla planifiés pour la
journée ;
2. Un ensemble de changements gérés grâce au contexte de tâche ;
3. Un éditeur de tâches avancé ;
4. Un mode centré sur les tâches dans l'explorateur de packages d'Eclipse.
13
Il y a deux genres de tâches dans Mylyn :

Tâches locales qui sont stockées dans l’espace de travail (workspace) d'Eclipse. Elles sont
privées et visibles seulement par l'utilisateur local. On dispose de fonctionnalités de
gestion de tâches basiques, comme la planification.

Tâches externes qui sont stockées dans un dépôt de tâches, c'est-à-dire une application
ou un serveur externe. Elles sont souvent partagées entre les développeurs, mais
bénéficient quand même des mêmes fonctionnalités que les tâches locales, comme la
planification personnelle et les notes.
Mylyn permet de travailler de manière unifiée avec divers types de dépôts de tâches, parmi
lesquels on peut citer :
 dépôt de tâches locales : une sorte spéciale de dépôt utilisé pour travailler avec des
tâches simples ; elles sont stockées dans l’espace de travail de Eclipse ;
 dépôt de tâches partagées : si une équipe utilise un dépôt de tâches partagé, comme un
serveur Bugzilla, on peut utiliser ce dépôt pour collaborer sur des tâches avec les autres
membres de l’équipe ;
 dépôt de tâches de gestion de projet : quelques connecteurs, comme XPlanner,
fournissent des fonctionnalités de gestion de tâches qui permettent de les grouper par
phases de projet, par exemple ;
 dépôt de bugs et rapports d’amélioration : cela représente une sorte spéciale de tâches,
qui est en général partagée entre l’utilisateur d’un produit et l'équipe assurant le support.
Mylyn permet d'intégrer ces rapports de bugs à vos autres tâches pour que vous puissiez
les consulter en même temps.
14
Une architecture simplifiée de la gestion des tâches peut se présenter de la façon suivante :
15


AbstractTask est la classe abstraite représentant un bug. On y trouve, entre autres, les
attributs taskId, owner, priority, creationDate, modificationDate, dueDate.
Elle étend la classe abstraite AbstractTaskContainer et implémente l'interface
ITask, l'interface de définition d'un bug.
ITask présente deux éléments énumérés :
o SynchronizationState (qui prend les valeurs conflict, incoming, outgoing,
etc.)
o PriorityLevel (valeur de "P1" à "P5").
Elle comporte toutes les méthodes d'interrogation des attributs contenus dans
AbstractTask et étend deux classes :
o IRepositoryElement qui contient a priori l'URL du dépôt de bug référencé
o IAttributeContainer qui contient apparemment les méthodes de manipulation
d'un mapping (Map) entre une clé d'attribut et la valeur de cet attribut
La classe LocalTask étend AbstractTask et semble être la classe qui définit un bug par
défaut.
D'une manière plus générale, Mylyn définit les dépendances suivantes entre les classes de
gestion des tâches :
16
17
4.3. La communication
Les connecteurs les plus matures, comme ceux de Bugzilla ou Trac, présentent les
fonctionnalités suivantes :
 Requête : c’est le mécanisme qui permet de récupérer des ensembles de tâches dans la
liste de tâches de Mylyn depuis le serveur externe. La manière de gérer les requêtes est
spécifique à chaque connecteur.
 Edition avancée : les tâches et les requêtes peuvent être éditées avec un éditeur intégré.
Cette fonctionnalité fournit un accès aux tâches et à d’autres éléments structurés via des
liens.
 Fichiers joints : des fichiers peuvent être déposés sur et récupérés depuis le dépôt
externe.
 Support hors-ligne : grâce à cela, on peut travailler même si on se déconnecte. Cette
fonctionnalité comprend aussi les notifications de changement, qui vous permettent
d’utiliser la liste de tâches comme une boîte de réception pour vos tâches au lieu d'utiliser
votre logiciel de messagerie.
Si le connecteur pour un dépôt de tâches n’existe pas, on peut toujours :
 utiliser les fonctionnalités de Mylyn pour créer des tâches locales ;
 utiliser le « Generic Web Repository Connector » qui permet une gestion de requêtes
basique pour de nombreux dépôts munis d'interfaces web tels que Google Code Hosting,
IssueZilla, GForge, SourceForge, phpBB, etc ;
 demander au responsable du dépôt de tâches de créer un connecteur pour Mylyn ;
 créer son propre connecteur.
Dans notre cas, le connecteur pour Debbugs n’est pas encore disponible. L’approche à venir
est donc soit d’utiliser le Generic Web Repository Connector, soit de créer soi-même le connecteur
propre pour Debian.
18
5. Bilan du projet
5.1. Les difficultés rencontrées
Nous avons rencontré plusieurs difficultés qui nous ont empêchés d’implémenter le
connecteur. Quelques-unes d’entre elles sont listées dans cette partie.
Tout d’abord, la compréhension du sujet n’a pas été évidente puisque nous avons eu du mal à
faire la distinction entre le but et le contexte propre à notre projet, et sa contribution au projet
Helios. Nous ne voyions pas très bien non plus ce que nous devions prendre en main en tant
qu’utilisateur et en tant que développeur.
Ensuite, l’étude même du code a mis du temps à débuter puisque nous pensions pouvoir
trouver toutes les informations nécessaires au projet en cherchant simplement sur Internet. Coté
Mylyn, la plongée dans le code a été plutôt douloureuse puisque nous nous sommes retrouvés face à
plus d’une centaine de classes non commentées et quasiment aucune documentation
supplémentaire. Dans la même optique, nous n’avons pensé que très tardivement à utiliser un outil
pour nous aider à voir les dépendances entre les classes, ce qui aurait pu nous aider à déterminer
plus rapidement l’architecture fonctionnelle de Mylyn. Une première configuration de Doxygen a
conduit à la génération de plus de 2000 fichiers image. Certains présentent des schémas qui
pourraient certainement être utiles à l'analyse du code mais le logiciel nécessite clairement une
configuration plus fine afin d'être utilisé au meilleur de sa capacité.
Dans une moindre mesure, l’utilisation des outils mis à disposition (wiki, svn) s’est révélée
ardue pour des utilisateurs peu familiers des concepts en jeu.
Cependant, le projet et ses difficultés ont aussi été enrichissants sur bien des aspects.
Nous avons pu entrer de plain-pied dans un projet entièrement open source et nous avons
appris à faire appel aux ressources de la communauté en communiquant directement avec ses
membres ou en les sollicitant via les listes de diffusion.
Par ailleurs, ce projet nous a permis de prendre en main différents outils (wiki, svn, doxygen,
gliffy). Ainsi, au-delà de leur utilisation propre, nous pourrons penser à utiliser des applications du
même genre dans d’autres projets.
5.2. Justification de la révision des objectifs
Comme il a été dit précédemment, aucun connecteur n’a été implémenté. Les tentatives de
compréhension du code source de Mylyn se sont avérées plus difficiles et longues que prévu. Suite
aux difficultés rencontrées Vers le début du mois de décembre, il apparaissait difficile de réaliser les
développements. Les encadrants nous ont alors conseillé de nous rapprocher des besoins du projet
Helios WP3.
Au mois de janvier, l’objectif principal est donc devenu la génération de documentation
permettant une meilleure compréhension de la gestion des tâches dans Mylyn.
5.3. La documentation laissée à disposition
Nous mettons à disposition des encadrants :
- plusieurs schémas d’architecture de Mylyn pour la gestion des tâches,
- le présent rapport, qui pourrait aider à un futur développement d’un connecteur,
- le contenu du wiki,
- un fichier dressant un comparatif entre les attributs des tâches (ou bugs) de
différents bugtrackers. Ceci pourrait représenter une bonne base pour la
19
généralisation des définitions de bugs dont il est fait mention dans le projet Helios
WP3 (via des ontologies16, par exemple).
D’autre part, d’intéressantes discussions, se rapprochant grandement des problématiques du
projet Helios WP3, ont été initiées sur la liste de diffusion des intégrateurs de Mylyn et pourront être
poursuivies par les encadrants.
16
https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/EvoOntBom
20
Conclusion
Ce projet nous a permis de suivre une démarche de projet de type libre.
En effet, l’utilisation d’un Wiki afin de traiter les avancées est plutôt une façon de procéder
que l’on retrouve dans les projets open source. Elle pourrait être rapprochée des démarches de
Knowledge Management (KM) dans l’entreprise. De plus, les systèmes de gestion de versions de
fichiers, tels que le svn, sont utilisés dans la grande majorité des projets, qu’ils soient propriétaires ou
libres.
Nous avons par ailleurs pu développer notre autonomie en prenant contact avec les acteurs
de la communauté open source ou bien en trouvant des outils adaptés aux besoins de notre analyse.
Les encadrants pourront utiliser la documentation fournie pour faire avancer la
généralisation de définition de bug et les communications entre différents bugtrackers (objectifs du
projet Helios). Par ailleurs, s’ils souhaitent qu’un connecteur soit implémenté pour Debbugs, les
ressources laissées à disposition faciliteront certainement la tâche des futurs développeurs lors
d’éventuels projets autour de Mylyn.
21
Annexes
Cas d'utilisation : le connecteur Mantis
Mantis est un système de bug-tracker à base de web ; il est écrit en PHP et travaille avec
MySQL ou PostgreSQL et un serveur de web. Les navigateurs Internet sont capables de fonctionner
comme un client à ce système.
Le projet de « Mylyn-Mantis Repository Connector » construit un connecteur pour Mantis Bug
Tracking application en utilisant l’interface SOAP de Mantis : « MantisConnec » qui est un php web
service basé sur l’API de Mantis.
L’architecture de connecteur de Mylyn-Mantis :
5.3.1. Extensions


Mantis
Connector :
C’est
un
connectorCore
lié
au
« org.eclipse.mylyn.tasks.ui.repositoires ».
Il
s’applique
à
la
classe
« MantisRepositoryConnector » dans le paquet « com.itsolut.mantis.core ».
Mantis Repository UI : Il s’applique à la classe « MantisRepositoryUI » dans le
paquet « com.itsolut.mantis.ui.tasklist ».
5.3.2. API de tâche
Paquet UI (com.itsolut.mantis.ui) contribue toutes les extensions et fait référence au paquet
« Core » quand nécessaire.

Ajouter un dépôt
Pour ajouter le dépôt Mantis, il faut implémenter les classes suivantes:
Paquet
Classe
Classe Parent
Public Méthodes
com.itsolu
t.mantis.u
i
com.itsolu
t.mantis.u
i.internal
MantisUIPlugin
AbstractRepositor
yConnectorUi
MantisRepositoryUI
MantisRepositoryU
I
MantisTaskReposito
ryLinkProvider
AbstractTaskRepos
itoryLinkProvider
start,stop,getDeault,ha
ndleMantisexception et
etc.
getConnectorKind,
getNewTaskWizard,
getQueryWizard,
getSettingsPage,
hasSearchPage,
getSearchPage,
getLegendElements,
getTaskKindOverlay,
findHyperlinks, etc.
getTaskRepository
22
com.itsolu
t.mantis.u
i.tasklist

MantisRepositorySe
ttingsPage
AbstractRepositor
ySettingsPage
MantisTaskListMigr
ator
AbstractTaskListM
igrator
isPageComplete,
getMantisVersion,
getConnectorKind,
createAdditionalControl
s, validateSettings,
isValidUrl,
getvalidator
MantisTaskListMigrator,
getQueryElementNames ,
getTaskElementName ,
migrateQuery,
migrateTask
Lister les tâches dans un dépôt
Quand on veut créer une nouvelle tâche dans dépôt, on fait appel à la méthode
« canCreateNewTask » dans la classe « AbstractRepositoryConnector » implémentée par le dépôt. S’il
retourne vrai, ce dépôt sera inscrit dans la liste des dépôts disponibles.
Pour lister les tâches dans un dépôt comme Mantis, il faut implémenter les classes suivantes:
Paquet
Classe
Classe Parent
Public Méthodes
com.itsolu
t.mantis.u
i.wizard (po
MantisCustomQueryP
age
AbstractRepositor
yQueryPage
NewMantisQueryWiza
rd
NewMantisTaskPage
RepositoryQueryWi
zard
WizardPage
NewMantisTaskWizar
d
MantisTaskEditorPa
ge
MantisTaskEditorPa
geFactory
NewMantisTaskWiza
rd
AbstractRepositor
yEditorPage
AbstractRepositor
yEditorPageFactor
y
MantisTaskEditor
AbstracttasEditor
Page
TaskEditorRichTex
tPart
TaskEditorRichTex
tPart
createControl,
canFlipToNextPage,
getRepository,
setRepository,
isPageComplete,
getQueryUrl, applyTo,
setQueryTitle
addPages, canFinish,
performFinish
setVisible,
isPageComplete,
getRepositoryTaskData,
getSelectedProject,
init,addPages,getSelect
edProject
createPartDescriptors,
insertPart,
canCreatePageFor,
createPage,
getPageImage,
getPageText,
getPriority,
getConflictingIds
createPartDescriptors
ur supporter
la requête)
com.itsolu
t.mantis.u
i.editor
(pour réaliser
le rédacteur
de tâche)
MantisStepsToRepro
ducePart
MantisAdditionalIn
formationPart
23
createControl
createControl
Les deux attributs majeurs du bug sous Debbug : l'étiquette et
la sévérité
Tag (étiquettes)
Les étiquettes servent à décrire la nature du bug
Les valeurs possibles sont les suivantes :
 patch (rustine)
Une rustine ou une procédure facile à suivre pour résoudre le bogue est incluse dans les
enregistrements du bogue. S'il y a une rustine mais qu'elle ne résout pas le bogue
correctement ou cause d'autres problèmes, cette étiquette ne doit pas être utilisée.
 wontfix (ne sera pas corrigé)
Ce bogue ne sera pas corrigé. Peut-être parce que c'est un choix entre deux façons
arbitraires de faire les choses et que le responsable et celui qui a soumis le bogue
préfèrent des façons différentes de faire les choses, peut-être parce que changer le
fonctionnement entraînera des problèmes plus graves pour certains, ou peut-être pour
d'autres raisons.
 moreinfo (plus d'info)
Ce bogue ne peut pas être résolu tant que des informations supplémentaires n'auront pas
été fournies par celui qui a soumis le bogue. Ce bogue sera fermé si celui qui l'a soumis ne
fournit pas plus d'informations pendant une période de temps raisonnable (quelques
mois). C'est pour les bogues du type « Ça ne marche pas ». Qu'est-ce qui ne marche pas ?
 unreproducible (non reproductible)
Ce bogue ne peut pas être reproduit sur le système du responsable. L'assistance d'un tiers
est nécessaire pour diagnostiquer les causes du problème.
 help (aide)
Le responsable demande de l'aide pour traiter ce bogue.
 pending (en cours)
Une solution à ce bogue a été trouvée et une mise à jour sera faite prochainement.
 fixed (résolu)
Ce bogue a été corrigé ou contourné (par un envoi d'un non-responsable, par exemple),
mais il reste un problème qui doit être résolu. Cette marque remplace l'ancien niveau de
gravité « fixed ».
 security (sécurité)
Ce bogue décrit un problème de sécurité dans un paquet (par exemple, mauvaises
permissions permettant l'accès à des données qui ne devraient pas être accessibles,
dépassement de limite de tampon permettant à des gens de prendre le contrôle d'un
système par des moyens illicites, attaques par dénis de service qui devraient être
résolues, etc.). La plupart des bogues de sécurité devraient aussi être signalés par le
niveau de gravité critique (« critical ») ou grave (« grave »).
 upstream (original)
Ce bogue concerne la partie originale du paquet (et non la partie Debian).
 confirmed (confirmé)
Le responsable a examiné le bogue. Il le comprend et il est fondamentalement d'accord
avec lui. Mais il reste au responsable à le corriger. (L'utilisation de cette étiquette est
optionnelle ; elle est destinée principalement aux responsables qui doivent gérer un grand
nombre de bogues ouverts.)

fixed-upstream
Le bogue a été corrigé par le développeur amont, mais il n'est pas encore dans le paquet
(pour une raison quelconque : peut-être est-il trop compliqué de rétroporter le
changement ou trop insignifiant pour que cela vaille la peine de s'en occuper).
24

fixed-in-experimental
Le bogue a été corrigé dans le paquet de la distribution Experimental, mais pas encore
dans la distribution Unstable.

d-i
Ce bogue concerne le développement de l'installateur Debian. Il est prévu que cette
étiquette soit utilisée quand un bogue affecte le développement de l'installateur mais
qu'il n'est pas rempli contre un paquet qui fait directement partie de l'installateur.

ipv6
Ce bogue concerne le support du protocole IPv6 « Internet Protocol version 6 ».

lfs
Ce bogue concerne le support des gros fichiers (plus de 2 gigaoctets).

l10n
Ce bogue concerne la localisation du paquet.

potato
Ce bogue s'applique particulièrement à la version Potato de Debian.

woody
Ce bogue s'applique particulièrement à la version Woody de Debian.

sarge
Ce bogue ne doit pas être archivé avant qu'il soit résolu dans la distribution Sarge.

sarge-ignore
Ce bogue, empêchant l'intégration dans la prochaine version, doit être ignoré pour les
objectifs de publication de Sarge. Cette étiquette ne doit être utilisée que par le
responsable de publication ; ne la positionnez pas vous-même sans son autorisation
explicite.

etch
Ce bogue ne doit pas être archivé avant qu'il soit résolu dans la distribution Etch.

etch-ignore
objectifs de publication d'Etch. Cette étiquette ne doit être utilisée que par le responsable
de publication ; ne la positionnez pas vous-même sans son autorisation explicite.

lenny
Ce bogue ne doit pas être archivé avant qu'il soit résolu dans la distribution Lenny.

lenny-ignore
objectifs de publication de Lenny. Cette étiquette ne doit être utilisée que par le
responsable de publication ; ne la positionnez pas vous-même sans son autorisation
explicite.

sid
Ce bogue ne doit pas être archivé avant qu'il soit résolu dans la distribution Sid.

experimental
Ce bogue ne doit pas être archivé avant qu'il soit résolu dans la distribution Experimental.
Severity (sévérité)
La sévérité sert à définir le niveau de gravité de bug
Les valeurs possibles sont les suivantes (par ordre décroissant de gravité) :

critical (critique)

rend inexploitable des programmes qui ne lui sont pourtant pas associés, ou casse
globalement le système, ou cause de sévères pertes de données, ou encore crée une faille
dans la sécurité du système.
grave (grave)
25





rend le paquet en question inutilisable ou presque, ou cause des pertes de données, ou
introduit une faille de sécurité permettant l'accès aux comptes des utilisateurs qui se
servent du paquet.
serious (sérieux)
est une sévère violation de la charte Debian (grossièrement, il viole une directive « must »
ou « required »), ou, dans l'esprit du responsable du paquet ou du responsable de la
publication, rend le paquet indistribuable.
important (important)
est un bogue ayant un effet majeur sur l'utilité du paquet, tout en ne le rendant pas
complètement inutilisable.
normal (normal)
la valeur par défaut, applicable à la plupart des bogues.
minor (mineur)
un problème qui n'affecte pas l'utilité du paquet, et qui est a priori simple à résoudre.
wishlist (liste de souhaits)
pour une demande d'une fonctionnalité, et aussi pour un bogue très difficile à résoudre
du fait de la conception du paquet.
26

interfaçage du bugtracker debian pour mylyn

Transcription

Documents pareils

Etch se refait une beauté

Le LOGICIEL LIBRE à Billy-Berclau - Club LinuX Nord

Tuto debian net install

Le projet Debian

nguyen kévin 2ème année bts sio sisr

Les Logiciels Libres - Linux

Installation minimale de Debian avec serveur X - Debian

curriculum vitae

Installation d`un serveur Debian GNU/Linux

Tuning Debian - Linux Identity