Où déposer ses ressources ? Le post suit un rapport des répertoires de ressources UIMA existants.

Le CMU est un répertoire public. Il est possible de déposer/retirer des pears de 25 Mo maximum. Ceux-ci sont automatiquement vérifiés comme étant des pears. Cela marche avec Apache UIMA 2.3. Un service de dépot de ressources autres est indiqué mais ne semble pas fonctionner/ être disponible.

Concenant le répertoire Apache, il est possible de déposer une contribution chez Apache moyennant le respect de certaines conditions et en suivant une certaine procédure.

Les 3 répertoires suivants, DKPro, Julie lab, et U-Compare
sont privés. On ne peut faire que de la récupération de l'existant.


Le répertoire de uima-fr.org accueille indifféremment tout type de ressources (outils, composants, documentation, ...) dans différents formats. Il n'offre pour l'instant pas d'outil automatique de soumission et de gestion de ressoures et il convient de contacter les coordinateurs pour déposer une ressource.

Un bref coup d'oeil sur les dépots de ressources UIMA existant dans le monde. J'en compte disponibles en Allemagne, au Royaume Uni, au Japon, aux USA et depuis peu en France.

• the LTI repository at the Carnegie Mellon University
• the Apache repository 
• the DKPro repository at the Darmstadt University  *
• the Julie lab repository at the Jena University **
• the U-Compare project repository ***
• et bien entendu le depot de uima-fr.org promu notamment par le LINA de l'Université de Nantes ****  

* Iryna Gurevych, Max Mühlhäuser, Christof Müller, Jürgen Steimle, Markus Weimer, and Torsten Zesch and. 2007. Darmstadt knowledge processing repository based on uima. In Proceedings of the First Workshop on Unstructured Information Management Architecture at Biannual Conference of the Society for Computational Linguistics and Language Technology, Tübingen, Germany.


** Udo Hahn, Ekaterina Buyko, Katrin Tomanek, Scott Piao, John McNaught, Yoshimasa Tsuruoka, and Sophia Ananiadou. 2007. An annotation type system for a datadriven nlp pipeline. In The LAW at ACL 2007 – Proceedings of the Linguistic Annotation Workshop, pages 33– 40. Prague, Czech Republic, June 28-29, 2007. Stroudsburg, PA: Association for Computational Linguistics.

**** Nicolas Hernandez, Fabien Poulard, Matthieu Vernier, et Jérôme Rocheteau. 2010. Building a French-speaking community around UIMA, gathering research, education and industrial partners, mainly in Natural Language Processing and Speech Recognizing domains. To appear in LREC Proceedings 2010, Malta.

Lorsque l’on travaille avec Apache UIMA et que l’on ajoute un nombre important d’annotations, il arrive un moment où l’on va vouloir filtrer certaines de ces annotations en fonction d’autres. Ainsi, assez couramment on éprouve le besoin de devoir récupérer des annotations qui couvrent la même zone de texte qu’une autre. Par exemple :

• récupérer les mots contenus dans une phrases ;
• récupérer les paragraphes dans un document ;
• …

Il y a au moins deux approches dans Apache UIMA qui permettent de répondre à ce besoin : le subiterator et le FSMatchConstraint.

Utilisation du subiterator

L’approche basée sur le subiterator ne peut fonctionner que si les types que l’on cherche à accéder sont couverts par le type couvrant au sens de UIMA, c-à-d en terme de priorité des types (cf. [la javadoc de TypePriorities] ou cet email).

Considérons une annotation A qui couvre des annotations B de la manière suivante :

Il y a du texte et les annotations sont sur ce texte ...
[-----A:1-----]   [---A:2---]  [--------A:3--------]
 [B:1] [B:2]       [B:3]        [B:4]  [B:5] [B:6]

Dans l’exemple ci-dessus, nous sommes intéressés par les annotations B couvertes par l’annotation A:3, en d’autres termes les annotations B:4, B:5 et B:6.

La méthode est la suivante :

1. On récupère un pointeur sur l’annotation couvrante qui nous intéresse (A:3), à l’aide d’un itérateur par exemple ;
2. On récupére l’index des annotations couvertes (les B) ;
3. On appelle la méthode subiterator de l’index des annotations couvertes (B) en passant en paramètre l’annotation couvrante (A:3), la méthode nous retourne un itérateur sur les annotations B couvertes par A:3, soit B:4, B:5 et B:6.

Voici le code correspondant :

// Récupération des index
AnnotationIndex annAIdx = (AnnotationIndex) jcas.getAnnotationIndex(A.type);
AnnotationIndex annBIdx = (AnnotationIndex) jcas.getAnnotationIndex(B.type);
// On recherche ''A:3''
FSIterator annAIt = annAIdx.iterator();
while (annAIt.hasNext()) {
  A monA3 = (A) annAIt.next();
  // On récupére l'itérateur sur les annotations B couvertes par A3
  FSIterator annBSousA3It = annBIdx.subiterator(monA3);
  while (annBSousA3It.hasNext()) {
    // On récupére successivement B4, B5 et B6
    B annB = (B) annBSousA3It.next();
    System.out.println("Sous A3 : "+annB);
  }
}

Utilisation des contraintes (FSMatchConstraint)

Lorsque l’on ne connaît pas les priorités des types ou bien qu’elles ne correspondent pas à ce que l’on souhaite faire, il est nécessaire de passer par un mécanisme plus complexe (mais beaucoup plus puissant) : le système de contraintes d’index.

Dans le cas présent, nous allons définir une contrainte imposant que les attributs begin et end d’une annotation d’un type donné correspondent à une certaine valeur : celle de l’annotation couvrante. Puis nous pourrons générer un itérateur qui retournera les annotations de l’index qui respectent cette contrainte.

Voici l’implémentation d’une méthode qui fait cela :

/**
 * 
 * This method provides an iterator over typed annotations that either 
 * have an offset embedded in that of a given annotation in a document, 
 * or have the same offset as these annotation. 
 * 
 * @param theDocument  the document in which stand the source and
 *                                         target annotations
 * @param theAnnotation  the source annotation under which target 
 *                                         annotations that have to be drawn out
 * @param theType            the type of the target annotations that have 
 *                                         to be drawn out from the document under 
 *                                         the source annotation
 * @param isStrict              the boolean that defines the offset matching,
 *                                         offsets strictly equal if isStrict is true, begin 
 *                                         offsets greater or equal and end offsets less 
 *                                         or equal otherwise.  	
 * @return                           the iterator over the type theType annotations 
 *                                          which stand under the annotation theAnnotation 
 *                                          in the document theDocument 
 * 
 * @author Fabien Poulard
 * @author Jérôme Rocheteau
 * 
 * @license Apache 2.0
 */
public FSIterator subiterator(JCas theDocument, Annotation theAnnotation,Type theType,boolean isStrict) {
	// Ajout: déclaration de la variable type
	Type theAnnotationType = theAnnotation.getType();
	// On utilise le constraint factory
	ConstraintFactory theConstraints = theDocument.getConstraintFactory();
	// On définit les contraintes sur le début de l'annotation
	FSIntConstraint beginConstraint = theConstraints.createIntConstraint();
	if (isStrict) { 
		beginConstraint.eq(theAnnotation.getBegin());
	} else {
		beginConstraint.geq(theAnnotation.getBegin()); 
	}
	Feature beginFeature = theAnnotationType.getFeatureByBaseName("begin");
	FeaturePath beginPath = theDocument.createFeaturePath();
	beginPath.addFeature(beginFeature);
	FSMatchConstraint begin = theConstraints.embedConstraint(beginPath,beginConstraint);
	// ... puis sur la fin de l'annotation
	FSIntConstraint endConstraint = theConstraints.createIntConstraint();
	if (isStrict) {
		endConstraint.eq(theAnnotation.getEnd());
	} else {
		endConstraint.leq(theAnnotation.getEnd());
	}
	Feature endFeature = theAnnotationType.getFeatureByBaseName("end");
	FeaturePath endPath = theDocument.createFeaturePath();
	endPath.addFeature(endFeature);
	FSMatchConstraint end = theConstraints.embedConstraint(endPath, endConstraint);
	// JR: on définit une contrainte sur le type d'annotation
	FSTypeConstraint typeConstraint = theConstraints.createTypeConstraint();
	typeConstraint.add(theType); // 
	FeaturePath typePath = theDocument.createFeaturePath();
	FSMatchConstraint type = theConstraints.embedConstraint(typePath, typeConstraint);
	// On combine les contraintes
	FSMatchConstraint beginAndEnd = theConstraints.and(type,theConstraints.and(begin, end));
	// On génère un itérateur respectant ces contraintes
	FSIterator filteredIterator =
	theDocument.createFilteredIterator(theDocument.getAnnotationIndex().iterator(), beginAndEnd);
	return filteredIterator;
}

Cette méthode prend en paramètre le JCas dans lequel travailler, l’annotation couvrante (l’annotation A3 dans l’exemple précédent), le type d’annotation qui nous intéresse (le type B pour reprendre l’exemple précédent) et un booléen qui permet de préciser si l’on souhaite une correspondance exacte ou approximative des frontières.

Jérôme Rocheteau décrit en détail comment mettre en place un projet Eclipse pour le développement d'un composant UIMA. Il explique notamment comment activer la gestion de dépendances vers les bibliothèques uimaj-core et uimaj-tools avec Maven.

L'usage de Maven est a recommandé. Mais il requiert l'installation de plugin et un accès réseau au moins à la création pour la récupération des dépendances. Je détaille ici l'étape de création du projet et l'ajout de la UIMA Nature (qui requiert elle aussi l'installation de plugins eclipse disponibles dans un sous répertoire de votre UIMA_HOME depuis la 2.3) ainsi que comment déclarer manuellement les dépendances qui vont bien dans le projet Eclipse.

CREER UN PROJET ECLIPSE POUR LE DÉVELOPPEMENT D'UN COMPOSANT UIMA

1. Créer un nouveau Projet Java : File > New > Java Project > 
2. Donner un Project Name et vérifier le JRE (>=1.5) > Next > Libraries (vous pourrez toujours modifier le Build Path de votre projet Eclipse)
3. Ajouter les dépendances uima-core et uima-tools présentes dans UIMA_HOME/lib :
   
• soit par Add External Jar
  
• soit par Variable qu'il vous faudra étendre voire définir le répertoire qu'elle désigne. Préférez cette démarche qui faciliter la portabilité du projet au sein de différents workspaces
• Cette manipulation n'est pas nécessaire quand vous utilisez Maven
  
4. Finish
5. Ajouter la UIMA Nature : Dans la vue Package Explorer cliquer droit sur le projet > Add UIMA Nature

Apache UIMA utilise le même type de fichier de description pour désigner un composant ou une chaîne de traitement. On peut d'ailleurs voir un composant comme une chaîne de traitement qui a minima ne compte qu'un seul composant à exécuter. Le fichier descripteur est

• soit configuré comme primitif si il désigne un traitement élémentaire. La classe implémentant le traitement sera alors désignée.
• soit configuré comme aggregate si le descripteur référence d'autres descripteurs de fichiers primitif ou aggregate.

C'est de cette manière que l'on peut réaliser de l'encapsulation de traitement.

Le lien suivant explique comment exécuter une chaîne de traitement existantes avec UIMA (en ligne de commande, par un GUI hors Eclipse, au sein d'Eclipse).

Ces utilisations sont illustrées avec des descripteurs présents dans les exemples de code fourni avec UIMAJ. Dans le cadre de ce post nous allons utiliser des composants UIMA Annotator Addons, à savoir le

• WhiteSpaceTokenizer qui découpe en mots, TokenAnnotation, et phrases, SentenceAnnotation, un texte fourni en entrée
• SnowballAnnotator qui effectue une racinisation des TokenAnnotations et rajoute un trait stem aux TokenAnnotation
• Tagger qui rajoute un trait posTag aux TokenAnnotation

Nous réaliserons la construction de notre chaîne à partir d'Eclipse qui offre, à travers ses plugins, les éditeurs de descripteurs qui nous facilitent la tâche.

1. Créer un projet Eclipse pour le développement d'un composant UIMA 
2. Rendre accessible à votre projet les jar et les descripteurs des composants que vous souhaiter utiliser : 
• ajouter dans votre build path les jars des composants des composants que vous souhaitez manipuler
• placer les descripteurs des composants dans le repertoire desc ; personnellement j'ai créé une variable UIMA_ANNOTATOR_HOME et ai importé dans desc les différents fichiers descripteurs que je souhaitais. L'avantage est qu'Eclipse reproduit la structure parente des descripteurs ce qui aide pour s'y retrouver dans les descripteurs.
• placer les ressources de ces composants dans le répertoire resource
3. Dans la vue Package Explorer cliquer droit sur le répertoire desc du projet > New > Other > UIMA > optez pour "Analysis Engine Descriptor File" > Donner lui un nom 
• Personnellement je spécifie le nom des descripteur d'Analysis Engine avec le suffixe AE pour les distinguer des descripteurs de Type System (suffixe TS) par exemple).
4. Dans la vue Package Explorer cliquer droit sur le fichier descripteur que vous venez de créer > Open With > Component Descriptor Editor
5. Sur l'onglet "Overview", spécifier l'engine type : Aggregate
6. Sur l'onglet "Aggregate", 
• le bouton "Add" permet d'ajouter des composants présents dans les lib de votre projet. Par exemple les CR/CC de uima-tools. Privilégiez des import "By name". "By Location" permet d'ajouter des composants n'importe où sur votre système de fichier moyennant la spécification ultérieur de son descripteur.
• Le bouton "Find AE" permet de chercher tous les descripteurs des composants développés sous forme de projet Eclipse actuellement "ouvert" dans votre Workspace y compris le projet courant. Sans spécification, il retourne tous les descripteurs. Privilégiez des import "By name".
• Le Bouton "Add Remote" permet d'ajouter des composants déployés sur des machines distantes
• Ajouter les descripteurs "WhiteSpaceTokenizer", "SnowballAnnotator" et "HmmTagger"dans cet ordre avec le boutton "Add"
7. Sur l'onglet "Capabilities",  cliquer sur  "add Type" et cliquer sur les cases in/out de chaque type.  
8. Exécuter la chaîne (voir la section Exécuter sous Eclipse)

TODO

• Installer et utiliser des composants par runPearInstaller.sh 
• Déployer un composant pour un accès distant et ajouter des composants distants dans une chaîne locale
• Utiliser le flow controler
• Utiliser les UIMA Annotators Addons : OpenCalais Annotator s'interface avec un service web ; Dictionnary et RegExp Annotator requièrent l'ajout de ressources

La qualité du code développé dans le cadre des activités de recherche scientifique n’est pas toujours aussi bon qu’on pourrait l’espérer. Outre la nécessité (évidente à mes yeux) d’ouvrir le codes des activités scientifiques financées par l’État et les collectivités territoriales, il est également nécessaire de suivre de bonnes pratiques de programmation. L’écriture de tests unitaires et leur exécution régulière est une de ces bonnes pratiques.

Je présente dans ce billet un cas d’utilisation de la bibliothèque UUTUC, présentée lors du Workshop sur l’Ingénierie Logiciel, les Tests et l’Assurance Qualité pour le Traitement des Langues Naturelles (SETQA-NLP 2009), pour tester l’implémentation d’une bibliothèque développée et utilisée dans le cadre de ma thèse (tddts-uima-shingling).

Principe de UUTUC

UUTUC est une bibliothèque offrant un certain nombre de méthodes facilitant le processus de test des composants UIMA. On y trouve notamment un certain nombre de classes de type Factory qui facilitent la mise en place de chaînes de traitement simples pour expérimenter les composants.

À l’aide de ces classes, l’exécution d’un AE sur un simple fichier texte se résume à ces quelques lignes :

AnalysisEngine engine = 
  AnalysisEngineFactory.createAnalysisEngineFromPath("descriptors/tutorial/ex1/RoomNumberAnnotator.xml");
JCas jCas = 
  AnalysisEngineFactory.process(engine, "data/WatsonConferenceRooms.txt");

Le couplage de UUTUC avec JUnit permet de mettre en place un banc de tests unitaires :

• Afin de tester la conformité de l’implémentation avec les spécifications attendues ;
• Prévenir les problèmes de régression lors de l’évolution des composants

Écriture de tests unitaires

J’utilise le framework JUnit 4 pour les tests unitaires. Il suffit de faire précéder les méthodes considérées comme des tests par @Test pour qu’elles soient reconnues comme telles par JUnit. Exemple :

import org.junit.Test;
import static org.junit.Assert.*;
...
/**
 * This class defines the tests for the main methods of the Shingle class.
 */
public class ShingleTest {
  ...
  /**
   * This method just checks that the isComplete method works
   * @throws InvalidShingleException 
   * @throws OverloadShingleException 
   */
  @Test
  public void completeness() throws InvalidShingleException, OverloadShingleException {
	Shingle s1 = new Shingle(2);
	assertFalse( s1.isComplete() ); // before any adding
	s1.add( theShingleItems[0] );
	assertFalse( s1.isComplete() ); // after a first adding
	s1.add( theShingleItems[0] );
	assertTrue( s1.isComplete() ); // should be complete by now
  }
  ...
}

Combiné à UUTUC, il permet de mettre en place un environnement UIMA assez simplement. Ainsi dans l’exemple ci-dessous, nous définissons une méthode à exécuter avant chaque test (@Before) qui crée un JCas et y ajoute quelques annotations à l’aide des Factory de UUTUC :

/** Static data for testing */
private static String CAS_CONTENT = 
   "Suisse : inauguration d'une nouvelle synagogue, une première depuis 50 ans";
private static Integer[][] CAS_OFFSETS = { {0,6}, {9,21}, {22,24}, {24,27}, 
   {28,36}, {37,46}, {48,51}, {52,60}, {61,67}, {68,74} };
...
/**
 * This method is used to set up the testing environment, creating the
 * data necessary for the different tests methods.
 */
@Before 
public void setUp() throws UIMAException, IOException, ShinglingTestingException {
	// Set up a CAS with a couple of shingle items in
	TypeSystemDescription tsd = TypeSystemDescriptionFactory
			.createTypeSystemDescription("shingling-ts");
	theTestingCas = JCasFactory.createJCas(tsd);
	theTestingCas.setDocumentText(CAS_CONTENT);
	for(Integer[] idx: CAS_OFFSETS) {
		AnnotationFactory.createAnnotation(theTestingCas, 
						idx[0], idx[1], ShingleItem.class) );
	}
}

Malheureusement il y a assez peu de documentation concernant UUTUC. Il est ainsi régulièrement nécessaire d’aller jeter un œil au code source qui heureusement est très bien écrit.

Intégration avec Maven

Maven modélisant toutes les étapes du cycle de développement, il intègre une étape test entre le compile et le package. La gestion des tests unitaires se faisant quant à eux au travers du plugin maven-surefire-plugin.

Il faut tout d’abord rajouter dans le pom.xml les informations de dépendance sur UUTUC et JUnit :

<repository>
  <snapshots>
    <enabled>false</enabled>
  </snapshots>
  <id>uutuc-googlecode</id>
  <name>uutuc Google Code repository</name>
  <url>http://uutuc.googlecode.com/svn/repo/</url>
</repository>
...
<!-- UUTUC for testing -->
<dependency>
  <groupId>org.uutuc</groupId>
  <artifactId>uutuc</artifactId>
  <version>0.9.10</version>
  <optional>false</optional>
  <scope>test</scope>
</dependency>
<!-- JUnit 4 for testing -->
<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.3.1</version>
  <scope>test</scope>
</dependency>

Il suffit ensuite de faire appel au plugin maven-surefire-plugin qui prend en charge tout ce qui concerne les tests, sous réserve que ces derniers soient bien présents dans src/test/java :

<!-- Testing -->
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <reportFormat>brief</reportFormat>
    <useFile>false</useFile>
  </configuration>
</plugin>

Il est alors possible de lancer l’exécution des tests avec Maven :

$ mvn test
...
-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running tddts.uima.shingling.ShingleTest
Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.992 sec

Results :

Tests run: 16, Failures: 0, Errors: 0, Skipped: 0
...

Plus d’excuse pour ne pas tester votre code maintenant ! L’excuse de faire du prototypage pour la recherche n’en est pas une bonne dès que les résultats que vous publiez dépendent de la qualité dudit code. C’est votre intégrité et honnêteté scientifique qui est en jeux ;)

Il y a quelques temps j’avais écrit une documentation en interne dans mon laboratoire sur l’utilisation du ’’CAS Editor’’. À l’époque c’était assez éprouvant car ce dernier se présentait sous la forme d’une application RCP Eclipse.

Depuis la version 2.3.0, le CAS Editor a été intégré sous la forme d’un plugin Eclipse. L’occasion de remettre la doc au goût du jour et de la partager avec le reste du monde.

Avant propos

Avant toute chose il est nécessaire d’installer les plugins Eclipse de UIMA. Pour ce faire, il faut ajouter le dépôt Eclipse : http://www.apache.org/dist/incubator/uima/eclipse-update-site/ dans l’outil de gestion des plugins. Ensuite il suffit de rechercher UIMA et d’installer tous les plugins associés.

À noter que les personnes ayant installé les plugins des versions antérieures doivent simplement faire une mise-à-jour afin de faire apparaître le plugin CAS Editor qui n’était pas présent auparavant.

Un petit redémarrage d’Eclipse et vous devriez être paré pour la suite...

Initialiser un projet

Le fonctionnement du CAS Editor est lié à :

• une vue CAS Editor
• un projet CAS Editor

Ceci est spécifique à la version 2.3 d’UIMA et devrait évoluer dans les prochaines versions.

La vidéo ci-dessous illustre les étapes nécessaires à l’initialisation d’un projet et l’importation d’un corpus :

1. Créer un projet CAS Editor
2. Passe en vue CAS Editor afin d’accéder aux fonctionnalités spécifiques
3. Créer un répertoire corpus
4. Importer dans ce répertoire corpus des fichiers textes afin de les transformer en CAS
5. Ouvrir et visualiser le contenu des fichiers (CAS) du corpus

Ajouter des annotations manuellement

Il n’est possible d’ajouter des annotations que si le type d’annotation à ajouter est présent dans le Type System. Si toutefois vous ajoutez des types d’annotation à un Type System qui est déjà utilisé par le projet CAS Editor, les nouveaux types ne vont pas apparaître. Il est nécessaire de fermer puis réouvrir le projet.

Il y a deux façons d’ajouter une annotation dans un CAS, l’une permet d’ajouter la même annotation par un simple appuie sur Entrée :

1. Sélectionner le texte
2. Sélectionner le type d’annotation dans le Feature View
3. Appuyer sur Entrée

l’autre permet de choisir le type de chaque nouvelle annotation rajoutée :

1. Sélectionner le texte
2. Appuyer sur shift + entrée
3. Choisir l’annotation à ajouter

La vidéo ci-dessous illustre ces deux méthodes :

Utiliser un AE pour ajouter des annotations

Il est tout à fait possible d’utiliser directement un Analysis Engine directement dans le CAS Editor afin d’ajouter des annotations aux CAS. La procédure est toutefois un peu contraignante et surtout peu intuitive. Je vais décrire l’approche qui consiste à utiliser un composant empaqueté dans un PEAR.

Construction et installation du PEAR

Pour l’exemple je vais prendre le WhitespaceTokenizer, ce dernier a deux avantages pour ce tutoriel :

• Il est simple d’utilisation (pas de paramètres) et n’a pas de dépendances sur d’autres composants
• Il fait parti officiellement d’UIMA et distribué sur le site : UIMA Annotator Addons & Simple Server & Pear packaging tools

Il nous faut la version source du paquet UIMA Annotator Addons & Simple Server & Pear packaging tools. Une fois téléchargée, décompressez là quelque part et placez-vous dans le répertoire uimaj-annotator-addons-2.3.0-incubating/WhitespaceTokenizer/.

Il nous faut modifier un peu le pom.xml afin d’y ajouter les dépôts qui sont normalement déclarés dans le pom parent :

...
  <repositories>
    <repository>
      <id>apache</id>
      <name>Apache UIMA</name>
      <layout>default</layout>
      <url>http://people.apache.org/repo/m2-incubating-repository/</url>
    </repository>
  </repositories>
  <pluginRepositories>
    <pluginRepository>
      <id>apache</id>
      <name>Apache UIMA</name>
      <url>http://people.apache.org/repo/m2-incubating-repository/</url>
      <layout>default</layout>
    </pluginRepository>
  </pluginRepositories>
  ...

Il est alors possible de créer le PEAR avec maven en lançant dans le répertoire du WhitespaceTokenizer :

$ mvn package

Le pear est alors créé dans le répertoire target/ sous le nom WhitespaceTokenizer.pear. Il faut l’installer à l’aide du PearInstaller.

Une fois le PEAR installé, il faut créer un répertoire processing dans le projet du CAS Editor, y importer le descripteur PEAR, l’intégrer à un composant Agregate. On peut alors le faire tourner sur une partie du corpus.

La vidéo ci-dessous présente ces dernières phases :

Visualiser et modifier les annotations

Le but du CAS Editor est tout de même de pouvoir visualiser et manipuler les annotations, ce qui se fait dans l’éditeur.

La visualisation des annotations est configurable par le menu contextuel Show annotations où l’on sélectionne les annotations à afficher. Le mode de mise en valeur de ces dernières se configure dans les propriétés du projet.

Le parcours des annotations s’opère de plusieurs manières :

• Par le menu contextuel, Mode permet de sélectionner la façon dont on parcours/sélectionne les annotations ;
• L’onglet Feature Structure View permet de sélectionner les types d’annotation à faire apparaître dans l’onglet Outline, il alors possible dans ce dernier de supprimer des annotations (croix rouge) ;
• Les onglets Edit View permettent quant à eux de modifier les valeurs des champs de l’annotation sélectionnée.

La vidéo ci-dessous illustre ces différentes manipulations :

Wikipedia est une incroyable source d’information, de données et plus généralement d’actes langagiers (utilisation du langage). C’est une ressource sans équivalent pour les chercheurs en traitement automatique des langues (TAL).

Le MediaWiki UIMA Loader est un composant UIMA, de type collection reader, permettant de tirer parti de Wikipédia pour la construction de corpus. La version 0.4 est la première release officiellement annoncée du composant.

Pour les impatients :

• Le jar du composant (et ses dépendances : mwdumper et wikimodel.wem)
• Les sources du composant

Présentation du composant

Le composant MediaWiki UIMA Loader est un collection reader permettant de charger des données issues d’un MediaWiki, notamment Wikipédia et ses projets dérivés ...

Le composant est distribué sous licence Apache 2. Vous pouvez donc l’utiliser dans le cadre d’un travail académique ou commercial. Dans les deux cas, si vous trouvez le composant utile, n’hésitez pas à me dire ce que vous en pensez, si vous souhaitez de nouvelles fonctionnalités ou si vous rencontrez des bugs.

Contrairement à plusieurs projets existant, le composant n’attaque pas directement les sites Wikipedia. Il ne nécessite pas non plus de créer un miroir local de la base de données MediaWiki. Il travaille directement à partir des dumps XML, ce qui présente les avantages suivant :

• Pas d’accès répétitifs aux serveurs des projets MediaWiki, préservant la bande passante et le temps de calcul de ces derniers ;
• Pas besoin de déployer un serveur de base de données en local et d’y importer les données de dump (si ça vous amuse, vous pouvez toujours suivre ce tutoriel) ;
• Limiter l’espace disque disponible pour stocker les informations en utilisant directement la version compressée des dumps ;
• Limiter la latence dans l’accès aux données provoquées par les requêtes réseau ou bien le serveur SQL.

Les fonctionnalités de cette version 0.4 sont les suivantes :

• Chargement à partir d’un dump XML compressé ou non ;
• Nombreuses options de filtrage (voir plus bas) concernant les pages et révisions à charger dans la chaîne de traitement ;
• Interprétation de la syntaxe wiki et annotation des Titres, Sections, Paragraphes et Liens (cf. ce billet pour plus d’informations).

Installation

Avant d’installer et d’utiliser le composant, il est nécessaire d’avoir un environnement UIMA installé. Si ce n’est pas le cas, se référer à ce tutoriel.

Le plus simple est de récupérer le jar du composant dans l’espace de téléchargement de uima-fr, ainsi que les dépendances : mwdumper et wikimodel.wem.

Si vous souhaitez reconstruire le jar vous mêmes, il vous faut télécharger les sources du composant, toujours dans l’espace de téléchargement de uima-fr,et les compiler à l’aide de maven :

$ tar -xzvf mediawiki-uima-loader-0.4.1.tar.gz
...
$ cd mediawiki-uima-loader-0.4.1
$ mvn package
...

Le jar devrait être créé dans le répertoire target/, les dépendances quant à elles auront été téléchargées dans votre dépôt maven local.

Utilisation

Vous pouvez utiliser le composant dans n’importe quelle chaîne de traitement UIMA, de la même façon que vous utilisez un composant classique de type collection reader. La démarche ci-dessous concerne l’utilisation de l’outil cpeGui, mais elle devrait être similaire pour les autres outils du même type.

Le cpeGui n’est pas capable en l’état de charger un descripteur xml depuis un jar. Avant tout, il est donc nécessaire d’extraire le descripteur du composant du jar afin de le rendre accessible. Si vous avez compilé le composant vous même, le descripteur est présent dans le répertoire desc. Sinon, il suffit de l’extraire du jar :

$ jar -x wikipedia-cr.xml -f mediawiki-uima-loader-0.4.1.jar

Il est nécessaire de rajouter le jar du composant et de ses dépendances dans le UIMA_CLASSPATH, avant de lancer le cpeGui en ligne de commande. Pour l’exemple, nous considérerons que le jar du composant est dans le répertoire courant et que les dépendances sont dans le dépôt maven local :

$ export UIMA_CLASSPATH=$UIMA_CLASSPATH:~/.m2/repository/org/wikimedia/mwdumper/1.16/mwdumper-1.16.jar:~/.m2/repository/org/wikimodel/org.wikimodel.wem/2.0.7-SNAPSHOT/org.wikimodel.wem-2.0.7-SNAPSHOT.jar:mediawiki-uima-loader-0.4.1.jar
$ cpeGui

Dans la partie de l’interface dédiée au Collection Reader, cliquez sur Browse et allez sélectionner le descripteur du composant que nous avons extrait du jar (wikipedia-cr.xml). L’interface se modifie afin d’offrir les champs de paramétrage du composant.

Le seul paramètre obligatoire est le champs Input Xml Dump. Vous devez renseigner dans ce dernier le chemin menant au dump XML de Wikipedia (ou tout autre dump MediaWiki) que vous souhaitez charger. Par exemple : ~/frwiki-20100111-pages-meta-history.xml.bz2. Le composant est capable de lire un dump, qu’il soit compressé ou non.

Les autres paramètres concernent le filtrage à mettre en place lors du chargement des données :

• Latest Revision Only, si vous cochez cette case seules la dernière révision disponible pour chaque article sera chargée, sinon toutes les révisions (présentes dans le dump) seront chargées ;
• Ignore Talks, si vous cochez cette case, les pages de type discussion seront ignorées, sinon elles seront également chargées ;
• Config Namespaces Filter, ce champs permet de spécifier les espaces de nom à considérer lors du chargement. S’il est laissé vide, tous les espaces de nom sont chargés. Pour wikipedia les espaces de nom disponibles sont :
  • -2 : ressources de type média ;
  • -1 : pages spéciales ;
  • 0 : espace de nom principal où l’on trouve les articles de l’encyclopédie ;
  • 1 : discussions à propos des articles ;
  • 2 : pages des utilisateurs ;
  • 3 : discussion à propos des utilisateurs ;
  • 4 : espace Wikipédia (le projet)
  • 5 : espace de discussion autour du projet Wikipédia
  • 6 : fichiers
  • 7 : discussion à propos des fichiers
  • 8 : espace MédiaWiki (le logiciel)
  • 9 : discussion à propos de MédiaWiki
  • 10 : modèles
  • 11 : discussion à propos des modèles
  • 12 : aide
  • 13 : discussion à propos de l’aide
  • 14 : catégories
  • 15 : discussion à propos des catégories
  • 100 : portail
  • 101 : discussion à propos du portail
  • 102 : projets
  • 103 : discussion autour des projets
  • 104 : références
  • 105 : discussion autour des références

Par exemple pour prendre en considération uniquement toutes les pages de discussion : 1,3,5,7,9,11,13,15,101,103,105, ou bien pour prendre en compte tous les espaces de nom excepté celui des catégories : !14 ;

• Config Title Match, ce champs permet à l’aide d’une expression rationnelle de filtrer les pages dont le titre valide l’expression rationnelle. Par exemple : A.* pour toutes les pages commençant dont le titre commence par A ;
• Config List Filter et Config Exact List Filter, ces champs permette d’indiquer en paramètre le chemin d’un fichier contenant un nom de page par ligne. Seules les pages précisées dans ce fichier seront chargées. Si c’est le paramétrage Exact qui est employé, le titre doit correspondre exactement, autrement le filtre vérifie s’il correspond au titre de l’article ou éventuellement de sa page de discussion ;
• Config Revision List Filter, ce champs permet de renseigner le chemin d’un fichier contenant en paramètre les numéros de révision à charger (une révision par ligne) ;
• Config Before Timestamp Filter et Config After Timestamp Filter, ces champs permettent de délimiter temporellement les données à importer en indiquant des dates limites de début et de fin au format yyyy-MM-dd’T’HH:mm:ss’Z’.

Une fois le composant paramétré, il suffit de renseigner les autres composants de la chaîne comme vous le faites habituellement et de lancer l’exécution.

Attention, si vous exportez le contenu traité par le composant, à l’aide du composant XmiWriter par exemple, à partir d’un dump compressé, prenez en compte que le volume de données risque d’être 20 à 100 fois supérieures à la taille originale du dump. Ainsi, il faut compter une vingtaine de Go minimum pour la version française de Wikipédia en ne considérant que les dernières révisions des articles.

On peut aussi réaliser les manipulations manuellement au sein d'Eclipse. Pour cela ajouter les sites suivants dans Eclipse (Help > Install new softwares). Redémarrer Eclipse entre chaque installation à l'aide de la commande eclipse -clean

1. http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/eclipse/ ; sélectionner  XPCOM et XULRunner ;
2. http://download.eclipse.org/releases/galileo (probablement déjà disponible dans vos Available Sofware Sites) ; sélectionner Eclipse Modeling Framework(EMF) ;
3. http://www.apache.org/dist/incubator/uima/eclipse-update-site ; sélectionner UIMA (version 2.3) ;
4. http://download.eclipse.org/technology/dltk/updates ; sélectionner le DLTK Core framework 1.0 ;
5. copier le contenu des répertoires plugins et features de l'archive de TextMarker dans les répertoires de même nom d'Eclipse

1. Importer le projet exemple dans votre workspace
2. Ouvrir la perspective TextMarker (Window > Open Perspective)
3. Stopper la construction automatique, nettoyer et relancer la construction afin de configurer les bons chemins dans tous les composants générés (Project > Stop Build Automatically and do Clean)

1. Vous pouvez ouvrir les fichiers.tm présents dans scripts avec le TextMarker Source Editor (Ouvrir avec >  TextMarker Source Editor) ; mais ce ne sont que des fichiers textes 
2. Supprimer les fichiers présents dans output
3. Lancer TextMarker en cliquant bouton droit Run As > Text Marker et en selectionnant Main.tm ; rien d'apparent ne se produit, mais le répertoire output se remplit à nouveau

 Constater que cela marche

1. Le répertoire output se remplit
2. Faire un open with Web Browser sur les fichiers html du répertoire output pour visualiser le résultat du traitement
3. Le mieux est de lancer un annotation viewer pour visualiser les annotations contenus dans le XMI ; un simple éditeur XML peut faire cela aussi sinon : Run as > Run configurations > Java Applications > org.apache.uima.tools.AnnotationViewerMain en spécifiant en input le répertoire output de TM et en spéciant comme TypeSystem le descriptors/de/uniwue/example/MainTypeSystem.xml. Attention il se peut que vous ayez besoin de lancer cela d'un projet java où les lib de UIMA sont déclarés et avec une copie du répertoire descripteurs de TM déclaré en répertoire source (éventuellement un jcasgen dans le MainEngine.xml)

Clean and rebuild the example project in order to set the correct paths in all generated components (also the path to the main script location). If the builder preference "import by name" is activated, then a new TextMarker project should rather be created in order to automatically include the correct UIMA datapath. Simply copy all elements into the newly created project afterwards.  

• Pour spécifier un data path à utiliser pour trouver une resource by name faire sur le projet bouton droit > Properties > UIMA CDE Property page > entrer autant de chemins absolus que souhaités séparés par le séparateur de classpath
• Pour configurer la résolution des imports à la création des descripteurs ou pour utiliser des imports by name à la création des descripteurs faire Window > Preferences > TextMarker > Builder

• Téléchargement : https://sourceforge.net/projects/textmarker/)
• Documentation : http://tmwiki.informatik.uni-wuerzburg.de

La création de composants UIMA permettant d’accéder et tirer parti de Wikipédia offrirait de nouvelles perspectives au traitement des langues en offrant un accès aisé à cette formidable ressource que représente l’encyclopédie libre. Je compte m’atteler à la création de tels composants et vais tâcher de publier plusieurs billets décrivant ma démarche en cours.

Voici le cinquième billet, plus orienté technique de développement, qui discute de la gestion du projet avec Maven, permettant notamment de gérer automatiquement les dépendances à MWDumper et à Wikimodel.

Qu’est-ce que Maven ?

Maven est une sorte de super-gestionnaire de projet qui peut se charger d’à peu près tout : dépendances, compilation, packaging, lancement des tests unitaires, ... L’outil est disponible sur la plupart des distribution, pour ma part sous Ubuntu :

$ sudo aptitude install maven2

L’objectif de ce billet est d’expliquer comment, à l’aide de notre génial ingénieur de recherche, j’ai pu utilisé maven pour gérer la construction du collection reader pour Wikipedia.

Récupérer les dépendances

La première complication lorsque l’on souhaite compiler le collection reader ce sont les dépendances, il y en a trois :

• UIMA, mais ceux qui veulent utiliser le composant doivent d’ores et déjà avoir réglé ce problème ;
• le projet mwdumper de MediaWiki ;
• le sous-projet org.wikimodel.wem de WikiModel.

Par chance tous ces projets sont déjà gérés par maven ce qui va fortement nous faciliter la tâche. Les étapes à suivre sont les suivantes :

1. Obtenir une version des sources de chacun des projets
2. Les compiler avec maven
3. Les installer dans le dépôt local de maven

Ainsi pour mwdumper :

$ svn co http://svn.wikimedia.org/svnroot/mediawiki/trunk/mwdumper
...
$ cd mwdumper
$ mvn compile
...
$ mvn install
...

Une fois ces étapes terminées, un nouveau dossier doit apparaître dans votre dépôt local : ~/.m2/repository/org/wikimedia/mwdumper/ ; il doit contenir un dossier correspondant à la version compilée (1.16 pour moi) et dans ce dossier les fichiers suivants :

• mwdumper-1.16.jar
• mwdumper-1.16.pom

Il faut procéder de la même manière pour WikiModel :

$ svn co http://wikimodel.googlecode.com/svn/trunk/org.wikimodel.wem
...
$ cd org.wikimodel.wem
$ mvn compile
...
$ mvn install
...

Vous devriez de la même manière voir apparaître dans votre dépôt local : ~/.m2/repository/org/wikimodel/org.wikimodel.wem/ ; il doit contenir une structure similaire.

Ces étapes sont nécessaires pour la suite car elles placent les dépendances dans le dépôt local de maven, là où il ira les chercher lors de la compilation.

Écriture du pom.xml

Revenons maintenant au composant UIMA. L’intelligence de Maven se configure dans un fichier à la racine du projet et nommé pom.xml.

Dans un premier temps, il faut définir le projet en lui donnant :

• Un identifiant de groupe (dans le cas où le projet appartiendrait à un groupe de projets) : groupId
• Un identifiant d’artefact, c-à-d de ce que le projet va produire : artifactId
• Spécifier une version : version
• Donner un nom et une description
• Renseigner les informations concernant les licences
• Spécifier le type de packaging que l’on souhaite obtenir

<project 
   xmlns="http://maven.apache.org/POM/4.0.0" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"
>
  <modelVersion>4.0.0</modelVersion>
  <groupId>uima.wikipedia</groupId>
  <artifactId>uima-mediawiki-loader</artifactId>
  <version>0.4</version>
  <packaging>jar</packaging>
  <name>MediaWiki UIMA Loader</name>
  <description>This is a UIMA Collection Reader for the MediaWiki dumps (Wikipedia &amp; co).</description>
  <licenses>
    <license>
      <name>Apache 2</name>
      <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
    </license>
  </licenses>
  ...
</project>

Dans un second temps, nous définissons les dépendances nécessaires à la construction de notre composant. Comme nous l’avons vu précédemment, il y en a plusieurs :

• UIMA, et plus précisément uimaj-core et uimaj-document-annotation
• WikiModel, et plus précisément org.wikimodel.wem
• MWdumper

Les dépendances se déclarent entre les tags <dependencies>, en indiquant notamment la version nécessaire.

...
  <dependencies>
    <!-- Required to generate the Java classes -->
    <dependency>
      <groupId>org.apache.uima</groupId>
      <artifactId>uimaj-core</artifactId>
      <version>2.3.0-incubating</version>
      <scope>compile</scope>
    </dependency>
    <!-- DocumentAnnotation UIMA Type --> 
    <dependency>
      <groupId>org.apache.uima</groupId>
      <artifactId>uimaj-document-annotation</artifactId>
      <version>2.3.0-incubating</version>
      <scope>compile</scope>
    </dependency>
    <!-- WikiModel -->
    <dependency>
       <groupId>org.wikimodel</groupId>
       <artifactId>org.wikimodel.wem</artifactId>
       <version>2.0.7-SNAPSHOT</version>
    </dependency>
    <!-- WikiMedia Dumper -->
    <dependency>
        <groupId>org.wikimedia</groupId>
	<artifactId>mwdumper</artifactId>
	<version>1.16</version>
    </dependency>
  </dependencies>
  ...

Comme vous l’avez certainement remarqué, on a précisé que le projet dépendait d’UIMA, mais contrairement aux dépendances sur MWDumper et WikiModel, nous n’avons pas installé ces dernières dans le dépôt maven local. En fait Maven va être capable d’aller chercher tout seul ces dépendances grâce au dépôt maven mis en ligne par Apache UIMA. Il suffit de préciser l’existence de ce dépôt :

...
  <repositories>
    <!-- Apache UIMA repository -->
    <repository>
      <id>apache</id>
      <name>Apache</name>
      <url>http://people.apache.org/repo/m2-incubating-repository</url>
    </repository>
  </repositories>
  ...

Finalement, on précise le processus de construction du composant entre les tags <build>. Dans nos cas cela revient tout simplement à préciser où aller chercher les sources, où placer les fichiers compilés et préciser ce qui doit être considérés comme des ressources et donc placé dans le Jar en plus des classes.

On utilisera de plus le plugin maven-compiler-plugin afin de préciser la version de Java que l’on souhaite pour la compilation.

...
  <build>
    <plugins>
      <!-- Java Compiler -->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>2.0.2</version>
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
        </configuration>
      </plugin>
    </plugins>
    <sourceDirectory>src</sourceDirectory>
    <outputDirectory>bin</outputDirectory>
    <resources>
      <resource>
        <directory>desc</directory>
      </resource>
    </resources>
  </build>
  ...

Le pom.xml est suffisant à cette étape pour permettre de lancer la compilation du projet et le packaging.

$ mvn compile
...

Vous devriez constater que le dossier bin s’est peuplé des classes compilées.

$ mvn package
...

Vous devriez maintenant constater l’apparition d’un dossier target dans lequel vous trouverez notamment un Jar nommé : uima-mediawiki-loader-0.4.jar. Et voilà, dans l’état il est possible d’obtenir un Jar du projet à partir des sources sans trop de problèmes. Toutefois la première étape de récupération des dépendances me paraît trop contraignantes. Il est possible, à l’instar d’Apache UIMA, de mettre en place un dépôt contenant des versions compilées des dépendances afin que maven aille directement les chercher.

Mettre en place un dépôt pour les dépendances

Un dépôt maven ce n’est ni plus ni moins qu’un système de fichiers respectant une certaine structure et accessible par http (par exemple).

J’ai créé un dossier sur mon serveur que j’ai rendu accessible par http à l’aide d’Apache, puis j’y ai collé l’arborescence concernant mwdumper et wikimodel quiu était présente dans mon dépôt local :

• ~/.m2/repository//org/wikimedia/...
• ~/.m2/repository//org/wikimodel/...

Il y a une petite nuance tout de même, lorsque le dépôt est distant, les fichiers doivent être accompagnés de leurs checksums afin de vérifier que le téléchargement s’est bien déroulé. Le plus simple pour générer ces fichiers de checksums est de réitérer l’installation dans le dépôt maven local avec une option supplémentaire :

$ mvn install -DcreateChecksum=true
...

Vous trouverez alors dans le dépôt local les fichiers en *.md5 et *.sha1 qu’il faut également transférer sur le serveur.

Une fois que le dépôt distant est mis en place, il suffit de le déclarer dans le pom.xml :

...
   <repository>
      <id>uima-fr.org</id>
      <name>UIMA Fr</name>
      <url>http://www.uima-fr.org/m2-repo/</url>
   </repository>
   ...

Il est maintenant possible de compiler le composant sans avoir à récupérer les dépendances en amont. Tout se fait automatiquement et de manière transparente pour l’utilisateur... c’est assez plaisant.

Comme je suis un fainéant, je trouve que ce serait cool de pouvoir déployer automatiquement mon composant sur mon dépôt, c’est tellement pratique les dépôts !

Déployer le composant sur le dépôt

J’ai choisi de pouvoir déployer mon composant sur le dépôt par ssh, pour des questions de sécurité. Mais il est également possible de le faire par ftp. Le déploiement par ssh nécessite tout d’abord de pouvoir se connecter automatiquement au serveur par ssh à l’aide d’un échange de clé, puis il suffit de renseigner dans le pom.xml l’adresse du dépôt et dans ~/.m2/settings.xml de préciser les modalités de connexion au dépôt.

Connexion automatique par ssh

Je ne vais pas détailler ici comment déployer un serveur ssh et faire tourner un ssh-agent en local, il y a tout un tas de tutoriels disponibles sur internet pour ça. Ce qu’il faut juste retenir, c’est que maven ne se connectera au serveur ssh si les deux conditions suivantes sont remplies :

• Le serveur est connu de ssh (il est enregistré dans .ssh/know_hosts) ;
• La connexion peut se faire par échange de clés (pas de mot de passe).

Le plus simple pour s’assurer de tout cela est de se connecter directement manuellement au serveur :

• Si le serveur est inconnu, ssh demandera s’il doit être ajouté à la liste des hôtes connus : acceptez ;
• Si le serveur vous demande un mot de passe c’est qu’il ne connaît pas votre clé, il suffit de lui donner.

Copiez donc le contenu de votre clé publique que vous trouverez dans le fichier ~/.ssh/id_dsa.pub ou bien ~/.ssh/id_rsa.pub. Elle doit ressembler à quelque chose comme ceci :

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAzqedhFIi8hy743U7pEvLMQvCEeAo/CxmLjF4jF2WguguN+U/4GsJrONvgoWMYXRn0zVMoHNpCEXQ+BT80ZTnv+MILu5elgFsE18bFA+7qjd454LwuZpoIoJOsCNyJKyGjy7ER5cZGN/z8G6cmSJTGauc270W7WJQELqKM3rfqPJH4FXPF9+WDP4UK/o7k54g36/3hHeBmqW++mpyEwkm0eT+GlBRlmP4NjVJACMoyYwl2S1Ep/m85aYR+95m3neHFZpUPmEyN52/Sod7ak28AHZ0M5oE/nRoUr1AAc0LzJw7BM327fAO6o7iHcfoIdo7pix2KLoteqT8tQIRQUmzxQ== grdscarabe@grdscarabe-desktop

Attention, cette clé se trouve sur le poste client à partir duquel maven se connaîtra !

Copiez donc cette clé dans le fichier ~/.ssh/authorized_keys, si ce fichier n’existe pas créez-le. Faites bien attention à ce qu’il soit dans le répertoire personnel de l’utilisateur que maven utilisera pour se connecter (le votre très certainement).

Une fois cette opération effectuée, vous devriez pouvoir vous connecter au serveur sans que ce dernier ne vous demande de mot de passe. Il se peut que si vous ayez protégé votre clé privée par un mot de passe, le ssh-agent vous le demande. Dans ce cas vous êtes de mon point de vue suffisamment au courant du problème pour ne pas lire cette section. Sinon vous êtes bien malin d’avoir mis un mot de passe :)

Déclaration du dépôt dans le pom.xml

Il suffit de déclarer dans le dépôt dans le pom.xml, nous l’appellerons ici uimafr-repository. Il est également nécessaire de charger l’extension wagon-ssh-external qui permet à maven de déployer par ssh :

...
   <extensions>
      <!-- Enabling the use of SSH -->
      <extension>
        <groupId>org.apache.maven.wagon</groupId>
         <artifactId>wagon-ssh-external</artifactId>
         <version>1.0-beta-6</version>
      </extension>
   </extensions>
   <distributionManagement>
      <repository>
         <id>uimafr-repository</id>
         <url>scpexe://www.uima-fr.org//home/www-data/org_uima-fr_www/m2-repo</url>
      </repository>
   </distributionManagement>
   ...

Modalités de connexion au dépôt

Enfin, il faut localement configurer maven pour reconnaître le dépôt uimafr-repository. Cette configuration se fait par le fichier ~/.m2/settings.xml. S’il n’existe pas, créez-le puis copiez-collez y le contenu suivant :

<settings>
  <servers>
    <server>
      <id>uimafr-repository</id>
      <configuration>
        <sshExecutable>ssh</sshExecutable>
        <scpExecutable>scp</scpExecutable>
      </configuration>
    </server>
  </servers>
</settings>

En gros ce dernier permet de préciser quels sont les outils à utiliser pour la connexion ssh. Sous linux, nous utiliserons les outils ssh pour la connexion et scp pour le transfert de fichier.

Déploiement

Et voilà, maintenant pour déployer mon composant sur le dépôt, il me suffit de faire :

$ mvn deploy
...

Elle est pas belle la vie ?

Extensions possibles

Il y a bien des extensions possibles pour rendre maven encore plus pratique pour la gestion de ce projet. J’en vois notamment deux :

• La génération automatique des classes de types UIMA à partir de JCasGen ;
• L’empaquetage dans le même Jar du projet et des dépendances sur MWDumper et WikiModel.

Dans le premier cas, la solution au problème doit certainement se trouver du côté du ’’exec-maven-plugin’’. Dans le second cas, il faudrait aller voir du côté de ’’maven-assembly-plugin’’.

Nouvelle version du composant

Et je conclus ce looong billet en distribuant la nouvelle version, estampillée 0.4, du collection reader pour Wikipedia : par ici ! Vous trouverez les dépendances nécessaires à son fonctionnement dans le dépôt maven de uima-fr.

Vous pouvez tester le composant à l’aide du cpeGui :

$ UIMA_CLASSPATH=~/.m2/repository/uima/wikipedia/mwuima-loader/0.4/mwuima-loader-0.4.jar:~/.m2/repository/org/wikimedia/mwdumper/1.16/mwdumper-1.16.jar:~/.m2/repository/org/wikimodel/org.wikimodel.wem/2.0.7-SNAPSHOT/org.wikimodel.wem-2.0.7-SNAPSHOT.jar cpeGui

Bien sûr, si vous n’avez pas installé le composant avec maven, il faudra modifier en conséquence les chemins du UIMA_CLASSPATH.

Autres articles

• UIMA & Wikipédia (1) : Proposition de Type System
• UIMA & Wikipédia (2) : Chargement d’un dump Wikipedia
• UIMA & Wikipédia (3) : Filtrage des données à charger
• UIMA & Wikipédia (4) : Analyse de la syntaxe MediaWiki