La branche « default » est la branche de développement qui est toujours la plus à jour (HEAD dans le monde svn).

La branche « stable » est la branche contenant uniquement des versions stables. Le contenu de la branche « stable » correspond à la dernière release officielle. On utilise cette branche pour la correction de bugs urgents (hotfix).

Les actions Mercurial sont réalisées au moyen de la commande « hg ». Certaines actions concernent le dépôt local (interactions entre les sources et le dépôt local),  d’autres concernent le dépôt central (interactions entre le dépôt local et le dépôt central). Les commandes locales seront indiquées en bleu et les autres en rouge.

Pour l’exemple, le projet s’appelle « HelloWorld ». Le but est de commencer avec les 2 dépôt (local et central) synchronisés.

Cas 1 : le projet est totalement nouveau, il n’y a ni dépôt local, ni dépôt central

Créer un dépôts « HelloWord » central sur Bitbucket

On obtient l’url d’accès au dépot : ssh://hg@bitbucket.org/bejean/helloworld

Créer un dépôt local

$ mkdir /Projects/HelloWord
$ cd /Projects/HelloWord
$ hg init

Cas 2 : le projet existe dans un dépôt central

Créer un dépôt local et récupérer les sources du dépot central.

$ mkdir /Projects/HelloWord
$ cd /Projects/HelloWord
$ hg init

$ hg clone ssh://hg@bitbucket.org/bejean/helloworld

(cette commande met à jour à la fois le dépôt local et les sources, elle devrait être bleue et rouge)

Cas 3 : le projet existe dans un dépôt local

Créer un dépôt central.
On obtient l’url d’accès au dépôt : ssh://hg@bitbucket.org/bejean/helloworld

Se placer dans le dépôt local et envoyer les sources dans le dépôt central.

$ cd /Projects/HelloWord
$ hg push ssh://hg@bitbucket.org/bejean/helloworld

Pour la suite de cet article, nous supposons que l’on est dans le cas 1. On a alors nos dépôts créés mais vides.

Configuration

Afin de ne pas devoir spécifier l’url du dépôt central pour toutes les commandes qui interagissent entre le dépôt local et le dépôt central (en rouge), nous allons commencer par configurer notre dépôt local.

On édite le fichier « hgrc » du dépôt.

$ cd /Projects/HelloWord
$ vi .hg/hgrc

et on ajoute la section suivante :

[paths]
default = ssh://hg@bitbucket.org/bejean/helloworld

Début de développement

Commençons à travailler dans notre environnent local. On créer un fichier en local

$ cd /Projects/HelloWord
$ touch readme.txt

hg status indique que le fichier est inconnu dans le dépôt local

$ hg status
? readme.txt

On ajoute le fichier dans le dépôt local

$ hg add readme.txt

hg status indique que le fichier est connu dans le dépôt local mais pas à jour

$ hg status
A readme.txt

On met a jour le fichier dans le dépôt local

$ hg commit -m "Premiere version du fichier" readme.txt

hg status n’indique plus de fichier inconnus ou non à jour.

hg branches indique maintenant qu’il existe une branche « default »

$ hg branches
default                        0:621365c7850a

Le dépôt central n’est toujours pas au courant du contenu du dépôt local. On envoi nos modifications dans le dépôt central.

$ hg push
pushing to ssh://hg@bitbucket.org/bejean/helloworld
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
remote: bb/acl: bejean is allowed. accepted payload.

La copie d’écran si dessous montre que le dépot central est à jour avec une branche « default »

Publication d’une première version stable (v1.0) : branches et tags

On considère que cette version des sources du projet est la première version stable. Il faut donc maintenant :

1/ tagger la version

$ hg tag v1.0

2/ créer une branche « stable » qui soit le reflet de la branche « default »

$ hg branch stable
$ hg commit -m "branch stable"

Afficher les tags, les branches et la branche active.

$ hg tags
tip                                2:88b63958bb97
v1.0                               0:621365c7850a

$ hg branches
stable                         2:88b63958bb97
default                        1:6d1c947c8a95 (inactive)

$ hg branch
stable

On met à jour le dépôt central avec la nouvelle branche.

$ hg push --new-branch

Voici un schéma qui récapitule les différentes actions et les différents flux.

Attention, à cette étape, la branche active est « stable ». Il faut revenir à la branche « default », pour coder de nouvelles fonctionnalités.

$ hg update default
$ hg branch
default

Le développement continu …

On modifie le fichier readme.txt et la commande hg status nous le confirme.

$ hg status
M readme.txt

on commit les modifications dans le dépôt local

$ hg commit -m "Ajout d'une fonction"

On peut vérifier les modifications locales transférables dans le dépôt central.

$ hg outgoing
comparaison avec ssh://hg@bitbucket.org/bejean/helloworld
searching for changes
changeset:   3:2b9ef639a08b
tag:         tip
parent:      1:6d1c947c8a95
user:        Dominique Bejean <dominique.bejean@eolya.fr>
date:        Sat Nov 19 20:16:49 2011 +0100
summary:     Ajout d'une fonction

Si ces modifications sont terminées, on peut les mettre à disposition des autres développeurs dans le dépôt central

$ hg push

De même on peut vérifier les modifications faites dans le dépôt central (par d’autres développeurs) et pouvant être récurées. Dans notre cas, il n’y en a pas.

$ hg incoming
comparaison avec ssh://hg@bitbucket.org/bejean/helloworld
searching for changes
aucun changement trouvé

Régulièrement, on récupère dans notre dépôt local les modifications faites par les autres développeurs et disponibles dans le dépôt central.

$ hg pull
$ hg update

Publication d’un nouvelle version (v2.0)

La publication d’une nouvelle version implique de :

1/ tagger la branche active (default)

$ hg tag v2.0

2/ mettre à jour la stable (merger default dans stable)

$ hg update stable
$ hg merge default

(gérer les conflits. il ne devrait pas y en avoir si les hotfixs fait dans stable ont systématiquement été mergés dans default)

$ hg commit -m "merge from default"

3/ revenir dans la branche de développement

$ hg update default

Le diagramme suivant illustre les séquences de commandes durant le cycle de production d’une nouvelle version :

Correction d’un bug dans la version stable

1/ se placer dans la version stable

$ hg update stable

2/ corriger le bug

$ vi readme.txt

3/ commiter la correction

$ hg commit -m "v2.0 fixe"

4/ revenir à la branche default

$ hg update default

5/ merger la correction de la branche stable et résoudre les potentiels conflits

$ hg merge stable
$ vi readme.txt
$ hg resolve -m readme.txt
$ hg commit -m "merge resolve"
$ rm readme.txt.orig

Comme référence, on trouve les 2 diagrammes suivants sur le site ivy.fr (licence Creative Commons Attribution 3.0 Unported).

Un autre diagramme (trouvé sur le site secretGeek) qui indique un workflow basic. Le point 6 (qui n’est pas systématique) doit être suivi d’un « hg up ».

Afin de gérer les sources du plugin et de travailler en équipe, on peut utiliser un outil de gestion de source tel que Git et utiliser Github comme repository central. Pour la passerelle Git vers SVN, on utilise alors la commande git svn et ses différentes actions.

Je ne décrirai pas ici comment fonction SVN et Git. Par contre, je souhaite expliquer comment j’ai pu résoudre un problème de mise à jour du repository SVN de WordPress lors de la livraison d’une nouvelle version d’un plugin.

Donc, après des modifications du plugin, je commit et je mets à jours github. Les commandes successives sont en simplifiant :

git commit ...
git push origin master

Jusque là tout va bien !

Après ceci, je veux mettre à jour le repoitory svn de WordPress puis tagger une nouvelle version du plugin et là patatra !

git svn dcommit
    Committing to http://plugins.svn.wordpress.org/browse-content-by-my-solr-server/trunk ...
    Merge conflict during commit: File or directory 'browse-content-by-my-solr-server.php' is
    out of date; try updating: resource out of date; try updating at
    /usr/local/git/libexec/git-core/git-svn line 579

Que ce fichier soit « out of date », je n’en doute pas car je l’ai bien modifié en local et après avoir mis à jour le repository github, c’est le repository SVN que je veux mettre à jour avec la commande « git svn dcommit » . J’ai l’impression que j’ai manqué quelque chose comme une opération « pull » en provenance de SVN et d’un « rebase » dans la foulée. Mais, étant le seul à travailler sur ce plugin, personne d’autre n’a fait évoluer le repository SVN parallèlement à mes modifications locales. Mystère !

Après de longues recherches sur cette erreur et aucune solution qui ne me permette de commiter et tagger dans svn, je trouve cet article qui me permet de repartir de zéro: http://danielbachhuber.com/2010/09/29/how-to-properly-use-git-with-wordpress-org-subversion/

La manipulation décrite rétablie le répertoire de travail local avec le contenu du SVN WordPress qui contient toujours la version précédente du plugin, puis, réinjecte les modifications qui sont dans le repository sur github. En gros, les étapes sont :

1. sauvegarder les derniers developpements locaux (tar …) et mettre tout cela de coter au cas où …
2. recloner le repository svn en local dans un répertoire travail vierge
3. récupérer la dernière version github qui est à jour avec les dernières modifications (mais sauvegardées par ailleurs au cas où)
4. commiter sous svn et tagger

Et dans la pratique, cela donne :

* Recréer le répertoire local de travail

cd <wordpress plugin dir>
rm -rf browse-content-by-my-solr-server
mkdir browse-content-by-my-solr-server

* Récupérer dans SVN le numéro de révision correspondant au dernier commit fait.

svn log https://plugins.svn.wordpress.org/browse-content-by-my-solr-server/

------------------------------------------------------------------------
 r436435 | dbejean | 2011-09-11 20:06:54 +0200 (Dim, 11 sep 2011) | 1 line

Create tag 1.1.0
 ------------------------------------------------------------------------
 r436432 | dbejean | 2011-09-11 19:58:50 +0200 (Dim, 11 sep 2011) | 1 line

template 3
...

On ne retient pas r436435 qui a été créé par une commande « git svn tag », mais r436432.

* Cloner le repository SVN dans le répertoire local de travail :

git svn clone -s -r436432 https://plugins.svn.wordpress.org/browse-content-by-my-solr-server/
cd browse-content-by-my-solr-server
git svn fetch

Note : « -s » est un raccourci pour   « -t tags -b branches -T trunk »

* Ré-associer le répertoire local de travail au repository Github

git remote add -f origin git@github.com:bejean/browse-content-by-my-solr-server.git
git checkout origin/master *
git add *
git commit -m "Updated from GitHub"

* Commiter et tagguer la nouvelle version du plugin dans le SVN WordPress

git svn rebase
git svn dcommit
git svn tag "x.x.x"

Et voilà le plugin est livré !

Il ne me reste plus qu’à trouver ce qui a provoqué cette erreur afin quelle ne se reproduise plus.

Il existe actuellement 2 versions en cours de développement : Solr 3.1 et Solr 4.0. Ma compréhension est que :

• Solr 3.1 est une version plutôt stable qui devrait la prochaine version de Solr et embarquent Lucene 3.1. Sortie possible : mars ou avril 2011.
• Solr 4.0 est la version de développement (trunk) moins stable et dont le disponibilité dervait être pour 2012.

Pour une explication sur ces 2 versions des sources de Solr, lire ce message de Uwe Schindler : Lucene 3.x branch created et cette discussion : Solr 3.1

Solr 3.1

Créer un répertoire de travail :

mkdir ~/solr-3.1

Se placer dans ce répertoire et récupérer les sources :

cd ~/solr-3.1
svn co http://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x

Compiler les sources :

cd ~/solr-3.1/branch_3x/lucene
ant dist
cd ~/solr-3.1/branch_3x/solr
ant dist

La javadoc est disponible ici : https://hudson.apache.org/hudson/job/Lucene-3.x/javadoc/all/index.html

Solr 4.0

Créer un répertoire de travail :

mkdir ~/solr-4.0

Se placer dans ce répertoire et récupérer les sources :

cd ~/solr-4.0
svn co http://svn.apache.org/repos/asf/lucene/dev/trunk

Compiler les sources :

cd ~/solr-4.0/trunk/modules
ant compile
cd ~/solr-4.0/trunk/lucene
ant dist
cd ~/solr-4.0/trunk/solr
ant dist

La javadoc est disponible ici : https://hudson.apache.org/hudson/job/Lucene-trunk/javadoc/all/index.html

Note du 2/11/2011 :

Le meilleur endroit pour récupérer les builds nocturnes ainsi que les liens vers les javadoc est : http://wiki.apache.org/solr/NightlyBuilds

Activation des modules apache :

sudo a2enmod status
sudo a2enmod info

Installation de Munin (voir http://www.howtoforge.com/server-monitoring-with-munin-and-monit-on-debian-lenny) :

sudo apt-get install munin munin-node libwww-perl
vi /etc/munin/munin.conf pour modifier [localhost.localdomain]
sudo /etc/init.d/munin-node restart

Activation de plugin Munin qui ne le sont pas par défaut (http://www.crashdump.fr/tutoriels/munin-le-top-du-monitoring-3/) :

sudo ln -s /usr/share/munin/plugins/apache_accesses /etc/munin/plugins/
sudo ln -s /usr/share/munin/plugins/apache_processes /etc/munin/plugins/
sudo ln -s /usr/share/munin/plugins/apache_volume /etc/munin/plugins/
sudo ln -s /usr/share/munin/plugins/netstat /etc/munin/plugins/netstat
sudo ln -s /usr/share/munin/plugins/uptime /etc/munin/plugins/uptime

Modification des droits pour le plugin netstat :

Créer le fichier /etc/munin/plugin-conf.d/netstat

sudo vi /etc/munin/plugin-conf.d/netstat

avec le contenu suivant

[netstat]
user root

Pour le monitoring des vhost apache :

http://stubbedtoe.co.nz/index.php/2009/09/apache-vhost-monitoring-with-munin/

Un plugin fail2ban :

http://www.majorxtrem.be/2009/08/14/plugins-fail2ban-pour-munin/

Penser à ajouter le droit d'exécution sur le plugin

sudo chmod +x /usr/share/munin/plugins/fail2ban

Pre-requis

Il s'agit des pre-requis consolidés pour Jira et Confluence, notament pour la configuration de Tomcat qui nécessite quelques ajustements.

Avoir JDK 6 de Sun (openJDK 6 n'est pas supporté par Atlassian), Tomcat 5.5 et MySQL 5.x installés.

Dans le fichier server.xml de Tomcat (/var/lib/tomcat5.5/conf/server.xml), ajouter le paramètre URIEncoding="UTF-8" au connecteur "non-SSL".

Dans le script de démarrage de Tomcat (/etc/init.d/tomcat5.5), ajouter les paramètres suivants pour le démarrage

if [ -z "$JAVA_OPTS" ]; then
    JAVA_OPTS="-Djava.awt.headless=true -Xmx768M -Duser.timezone=Europe/Paris -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -Dmail.mime.decodeparameters=true -XX:MaxPermSize=128m"
fi

Dans /usr/share/tomcat5.5/common/lib, copier le fichier jar du connecteur java de MySQL disponible via cette page : http://www.mysql.com/downloads/connector/j/

Jira

Il s'agit d'installer la version EAR-WAR de Jira. La procédure d'installation sur le site de Atlassian est à cette adresse :

http://confluence.atlassian.com/display/JIRA/Installing+JIRA+WAR-EAR

Créer la base de donnée en utf-8 et donner les droits à un utilisateur.

mysql> CREATE DATABASE jiradb CHARACTER SET utf8 COLLATE utf8_bin;
mysql> grant all privileges on jiradb.* to 'jira'@'localhost' identified by 'jira' with grant option;

Télécharger la distribution à l'adresse suivante : http://www.atlassian.com/software/jira/JIRADownloadCenter.jspa

Au besoin, choisir le bon OS et afficher toutes les versions disponibles ("show all" au dessus du bouton "download")

Contrairement à ce que demande la documentation sur le site de Atlassian, je ne créer pas de d'utilisateur "jira". J'installe Jira dans /opt/atlassian.

Décompresser la distribution dans /opt/atlassian et créer un lien symbolique

gunzip atlassian-jira-enterprise-4.1.2.tar.gz
tar xf atlassian-jira-enterprise-4.1.2.tar
sudo chown -R un_utilisateur: /opt/atlassian
ln -s atlassian-jira-enterprise-4.1.2 jira

J'indique le Jira home path dans le fichier /opt/atlassian/jira/jira/edit-webapp/WEB-INF/classes/jira-application.properties

jira.home = /opt/atlassian/jira

Donner les droits d'écriture à tout le monde dans le répertoires /opt/atlassian/atlassian-jira-enterprise-4.1.2, /opt/atlassian/atlassian-jira-enterprise-4.1.2/cache et /opt/atlassian/atlassian-jira-enterprise-4.1.2/plugins

Configurer la connexion à la base de données dans le fichier /opt/atlassian/jira/jira/edit-webapp/WEB-INF/classes/entityengine.xml 

<datasource name="defaultDS" field-type-name="mysql"
    helper-class="org.ofbiz.core.entity.GenericHelperDAO"
    check-on-start="true"
    use-foreign-keys="false"
    use-foreign-key-indices="false"
    check-fks-on-start="false"
    check-fk-indices-on-start="false"
    add-missing-on-start="true"
    check-indices-on-start="true">

et vérifier par la même occasion :

<transaction-factory class="org.ofbiz.core.entity.transaction.JNDIFactory">
    <user-transaction-jndi jndi-server-name="default" jndi-name= "java:comp/env/UserTransaction" /> 
    <transaction-manager-jndi jndi-server-name="default" jndi-name="java:comp/env/UserTransaction" />
</transaction-factory>

Construire Jira

cd /opt/atlassian/jira
./build.sh

Ajouter dans /usr/share/tomcat5.5/common/lib les librairies nécessaires à jira et qui se trouvent sur le site Atlassian à l'adresse : http://confluence.atlassian.com/download/attachments/200709089/jira-jars-tomcat5.zip?version=1&modificationDate=1252474277460

Stopper Tomcat

sudo /etc/init.d/tomcat5.5 stop

Copier le fichier /opt/atlassian/jira/dist-tomcat/tomcat-5.5/jira.xml dans /var/lib/tomcat5.5/conf/Catalina/localhost

Démarrer Tomcat

sudo /etc/init.d/tomcat5.5 start

Confluence

Créer la base de donnée en utf-8 et donner les droits à un utilisateur.

mysql> CREATE DATABASE confluence CHARACTER SET utf8 COLLATE utf8_bin;
mysql> grant all privileges on confluence.* to 'confluence'@'localhost' identified by 'confluence' with grant option;

Il s'agit de la version EAR-WAR de confluence. La procédure d'installation sur le site de Atlassian est à cette adresse : http://confluence.atlassian.com/display/DOC/Installing+Confluence+EAR-WAR+on+Tomcat

Télécharger la distribution à l'adresse suivante : http://www.atlassian.com/software/confluence/ConfluenceDownloadCenter.jspa

Au besoin, choisir le bon OS et afficher toutes les versions disponibles ("show all" au dessus du bouton "download")

Décompresser l'archive dans /opt/atlassian et créer un lien symbolique

gunzip confluence-3.3.3.tar.gz
tar xf confluence-3.3.3.tar
sudo chown -R un_utilisateur: /opt/atlassian
ln -s confluence-3.3.3 confluence

Donner les droits d'écriture à tout le monde dans le répertoire confluence-3.3.3

Editer confluence/WEB-INF/classes/confluence-init.properties afin d'indiquer le Confluence home path

confluence.home = /opt/atlassian/confluence

Créer un fichier confluence.xml dans le répertoire conf/Catalina/localhost de Tomcat qui contient :

<Context path="/confluence" docBase="/opt/atlassian/confluence/confluence" debug="0" reloadable="true" />

Redémarrer Tomcat

Se connecter à confluence pour exécuter le wizard : http://serveur:8180/confluence/

Problème connu

Les menus de Confluence ne fonctionnent pas ou Confluence ne démarre pas lorsque Conflunence et Jira sont hébergés dans le même serveur Tomcat.

Ces problèmes sont du au fait que ces deux produits utilisent une version différente d'une même librairie Atlassian. Il s'agit de org.apache.felix.main-2.0.0-atlassian-1.jar pour Jira et org.apache.felix.main-2.0.4-atlassian-3.jar pour Confluence. La solution consiste a :

• arrêter Tomcat
• sauvegarder org.apache.felix.main-2.0.0-atlassian-1.jar de Jira
• remplacer toutes les instances de org.apache.felix.main-2.0.0-atlassian-1.jar dans Jira (il y en a 2) par org.apache.felix.main-2.0.4-atlassian-3.jar de Confluence
• démarrer Tomcat

Cependant, cette méthode n’est pas fiable à 100% et NgramJ est limitée dans sa version actuelle à 26 langues détectables : Bulgare (bg), Tchèque (cz), Danois (da), Allemand (de), Grec (el), Anglais (en) Espagnol (es), Estonien (et), Finlandais (fi), Français (fr), Hongrois (hu), Islandais (is), Italien (it), Lituanien (lt), Letton (lv), Maltais (mt) , Néerlandais (nl), Norvégien (no), Polonais (pl), Portugais (pt), Roumain (ro), Russe (ru) , Slovaque (sk), Slovène (sl), Suédois (sv) et Thaï (th).

Je voudrais proposer 2 pistes pour améliorer NGramJ : la fiabilité de la détection et le nombre de langues détectables.

La fiabilité de la détection

NgramJ utilise un algorithme complexe de calcul statistique sur les n-grams et je n’ai pas la prétention de l’améliorer. Par contre, on peut facilement fournir des informations complémentaire à NGramJ afin qu’il oriente sa détection sur un sous-ensemble restreint de langues et non pas sur toutes les langues qu’il gère (surtout si on veut en augmenter le nombre).

Que connait-on du texte que l’on veut analyser ? On connait l’encodage de ses caractères (iso-8859-1, iso-8859-5, windows-1252, … et souvent unicode ou utf-8). Chacun de ces jeux de caractères permet d’écrire un ensemble plus ou moins important de langues (voir Character encoding). Unicode est particulier car il permet de coder toutes les langues, par contre une ou plusieurs langues partagent un sous ensemble d’unicode qu’il est facile d’identifier (voir Unicode 5.2 Character Code Charts). On peut donc pour un texte donné se limiter à la détection des langues couvertes par le sous ensemble unicode qu’il utilise.

Par exemple, pour un texte codé en iso-8859-5 (caractères cyrilliques) les langues possibles sont : Bulgare (bg), Biélorusse (be), Macédonien (mk), Russe (ru), Serbe (sr) et Ukrainien (uk). La seule langue que devrait donc nous proposer NGramJ si on lui demande de se retreindre à ces langes est le Russe. Ce n’est pas satisfaisant. En effet, je ne veux pas que NgramJ me dise qu’un texte Bulgare est du Russe. Plus loin dans cet article, on verra comment « appendre » de nouvelles langues à NgramJ.

Encore mieux, on peut sans même le demander à NgramJ connaitre la langue d’une texte. En effet, certains jeux de caractères permettent de coder une seule langue : iso-8859-15 (Estonien), iso-8859-9 (Turc), iso-8859-7 (Grec), …

En conclusion, même si on parvient à apprendre à NgramJ la totalité des langues existantes (et pourquoi pas), on pourra toujours lui indiquer de travailler sur un sous-ensemble réduit de deux à une dizaine de langues en fonction de l’encodage du texte.

Un point auquel il faut porter attention est qu’un même jeux de caractères peut avoir plusieurs noms voisins. On trouve sur le site de l’INIA, l’ensemble des jeux de caractères avec leur nom préféré et leurs alias.

Pour traiter cet aspect préliminaire à l’utilisation de NGramJ, j’ai développé une classe utilitaire CharsetLanguages qui permet de :

• Obtenir le nom préféré d’un jeux de caractères.
• Obtenir les blocs unicode utilisé pour l’écriture d’un texte
• Obtenir les langues associées à un jeu de caractères
• Obtenir les langues associées aux blocs unicode détectés dans un texte

Pour simplifier l’utilisation de NgramJ, j’ai également développé une classe LanguageRecognizerCngram qui permet de :

• Initialiser un contexte de détection en spécifiant le répertoire ou sont les fichiers de définitions des langues (fichiers modèles) et la liste des langues que l’on veut pouvoir détecter (si on sait à l’avance que les documents que l’on va traiter se limitent à ces langues)
• lancer la reconnaissance d’une langue dans un texte

Le code source de ces classes est fournie sous la forme d’un projet Eclipse. je fournie également la version compilée de NGramJ modifié. Ces modifications ont été transmises à l’auteur qui s’est proposé de les intégrer à la version officielle.

Voici un exemple de code pour l’utilisation de ces classes :

public static String getLanguage (String content, String charSet)
{
 
String language = null;
 
// Define the maximum length for the text to be analyzed
int languageDetectionLength = 2048;
 
// Define a list of candidate languages for the text
String languageDetectionList = "bg, ru, sr, uk";
 
content = content.substring(0, Math.min(content.length(), languageDetectionLength));
 
// Create the language detector
LanguageRecognizerCngram lrCnGram = new LanguageRecognizerCngram();
if (lrCnGram!=null)
{
    // Set the directory for the language models
    lrCnGram.setLanguageModelsDir("/Data/ngramj/ngp/ngp");
    if (languageDetectionList!=null && !"".equals(languageDetectionList))
    {
        // Create a list for the candidate languages
        String[] tab = languageDetectionList.split(",");
        ArrayList<String> arr = new ArrayList<String>(Arrays.asList(tab));
        for (int i=0;i<arr.size();i++) {
           arr.set(i, arr.get(i).trim());
        }
 
        // Set the candidate languages
        lrCnGram.setCandidateLanguages(arr);
    }
    else
    {
        // Try to get a candidate languages list according to the charset
        ArrayList<String> charSetCanditateLanguages;
        CharsetLanguages csu = new CharsetLanguages();
 
        if (charSet == null || "".equals(charSet))
            charSet ="utf-8";
        else
            charSet = csu.getCharsetCanonicalName(charSet);
 
        if ("utf-8".equals(charSet))
        {
            String s = csu.getUnicodeBlockDistribution (content);
            charSetCanditateLanguages = csu.getUnicodeBlockLanguages(s);
        }
        else
        {
            charSetCanditateLanguages = csu.getCharsetLanguages(charSet);
        }
 
        // Only one possible language so nothing else to do
        if (charSetCanditateLanguages!=null && charSetCanditateLanguages.size()==1)
            return charSetCanditateLanguages.get(0);
 
        // Set the candidate languages
        lrCnGram.setCandidateLanguages(charSetCanditateLanguages);
    }
 
    // Process the recognition
    language = lrCnGram.RecognizeLanguage( content, 0.5, null);
    return language;
}

Ajouter des langues à la liste de celles détectables par NGramJ

Pour ce travail, je me suis inspiré de l’article suivant « Generating a Plain Text Corpus from Wikipedia« .

Pour ajouter une nouvelle langue, les étapes sont :

• Récupérer un corpus significatif de texte écrit dans cette langue
• Nettoyer le texte
• Créer le fichier modèle avec NGramJ

Obtenir un corpus

Pour obtenir un corpus dans une langue donnée, il est possible de télécharger la totalité des articles de wikipedia dans cette langue. L’adresse dépend du code ISO de la langue :

http://download.wikimedia.org/<code iso>wiki/latest/<code iso>wiki-latest-pages-articles.xml.bz2

Par exemple, pour l’arabe, on récupère une archive et on la décompresse comme ceci :

curl -O http://download.wikimedia.org/arwiki/latest/arwiki-latest-pages-articles.xml.bz2
bunzip2 arwiki-latest-pages-articles.xml.bz2

Nettoyer le corpus

Pour nettoyer le fichier xml, je me suis inspiré de ce script.

Ma version est plus violent mais ne supprime pas ce qui n’est pas iso-8859-1.

wikicat2.sh :

#!/bin/sh
# http://wiki.apertium.org/wiki/Talk:Calculating_coverage#wikicat2.sh
# clean up wiki for running through apertium-destxt
# Use $ ./wikicat2.sh blah-pages-articles.xml.bz2
 
# awk prints full lines, make sure each html element has one
#bzcat "$@" | sed 's/&gt;/&gt;n/g' | sed 's/<!--n</g' |
cat "$@" | sed 's/-->/&gt;n/g' | sed 's/<!--n</g' |
# want only stuff between <text...--> and
awk '
//,/&lt;/text&gt;/ { print $0 }
' |
 
sed 's/[[([a-z]{2,3}):[^]]+]]//g' |
# Drop all transwiki links
 
sed 's/[[[^]|]*|//g' | sed 's/]]//g' | sed 's/[[//g' |
# wiki markup, retain bar and fie from [[foo|bar]] [[fie]]
 
sed 's/[http[^ ]*([^]]*)]/1/g' |
# wiki markup, retain `bar fie' from [http://foo bar fie]
 
sed 's/&amp;.*;/ /g' |
# remove entities greedily, so as to get rid of hidden html too
 
# Keep only lines starting with a capital letter, removing tables with style info etc.
# grep '^[ t]*[A-ZÆØÅ]' # Your alphabet here
grep -vE '^([|{=}!]|[a-z]{2,3}:)' |
 
# some other cleanup
grep -vE '^([a-z]{1,4}-[a-z]{1,4}:)' |
grep -vE '^([a-z]{1,4}-[a-z]{1,4}-[a-z]{1,4}:)' |
grep -vE '^s*[a-z]{0,2}s*$' |
grep -vE '^s*$' |
grep -vE "([|]|'{3})" |
 
# keep a raisonnable corpus size
head -n 2000

Et donc, pour générer un fichier nettoyé la commande est :

wikicat2.sh arwiki-latest-pages-articles.xml >ar.txt

Ce script peut être à améliorer en fonction de résultat obtenu. Quoi qu’il en soit, il faut tout faire pour nettoyer au mieux le texte et même terminer le travail à la main si nécessaire.

Créer le fichier model

Le fichier modèle est généré à partir du texte nettoyé avec la commande suivante :

java -jar cngram.jar -create ar ar.txt "UTF-8"

On peut enchainer automatiquement toutes ces taches en prenant soin de ne télécharger le corpus de wikipedia que si on ne l’a pas déjà. Voici comment préparer un environnement de travail et un script shell qui va enchainer toutes les opérations automatiquement pour une liste de langues.

1. dans un répertoire, on place cngram.jar et wikicat2.sh.

2. on y créer buildngp.sh

#!/bin/bash
 
mkdir data > /dev/null 2>&1
cd  data
mkdir ngp > /dev/null 2>&1
 
# for all these languages
for i in fr fa ar be mk sr uk; do
    echo $i
 
    # download file from wikipedia only if necessary
    if [ -f ${i}wiki-latest-pages-articles.xml ];
    then
        echo "${i}wiki-latest-pages-articles.xml exists in local"
    else
        # download
        curl -O http://download.wikimedia.org/${i}wiki/latest/${i}wiki-latest-pages-articles.xml.bz2
        # unzip the file
        bunzip2 ${i}wiki-latest-pages-articles.xml.bz2
    fi
 
    # cleanup the xml file to text file
    ../wikicat2.sh ${i}wiki-latest-pages-articles.xml > ${i}.txt
 
    # create cngram ngp file
    java -jar ../cngram.jar -create ${i} ${i}.txt "UTF-8"
    mv ${i}.ngp ngp/${i}.ngp
done

On lance le script ainsi en se positionnant dans le répertoire de travail :

./buildngp.sh

Les données sont téléchargées dans le sous-répertoire data et les fichiers ngp créés dans data/ngp. Dans le script, la ligne suivante permet de définir la liste des langues pour lesquels ont va générer un fichier NPG.

for i in fr fa ar be mk sr uk; do

Téléchargements

Télécharger le projet Eclipse CharsetLanguages

Télécharger les scripts de génération de fichier NGP pour NgramJ BuildNGP

Etape 1 : Récupérer les sources

Les sources sont disponibles à partir de la page http://lucene.apache.org/tika/download.html

Décompresser l’archive dans un répertoire de travail /tmp/tika-0.6

Etape 2 : Compilation.

Le moyen le plus simple est d’utiliser maven 2.

On se place dans le répertoire de travail

cd /tmp/tika-0.6

On positionne la variable d’environnement LC_ALL afin de ne pas avoir d’erreur durant la compilation (l’astuce) et on alloue par la même occasion suffisamment de mémoire de pour maven

export LC_ALL=en_US.UTF-8
export MAVEN_OPTS="-Xmx2048m"

On lance la compilation

mvn install

4 fichiers jar sont générés

find . -name *.jar -print

./tika-app/target/tika-app-0.6.jar
./tika-bundle/target/tika-bundle-0.6.jar
./tika-core/target/tika-core-0.6.jar
./tika-parsers/target/tika-parsers-0.6.jar

Pour utiliser Tika dans une application, seules les 2 jars suivants sont indispensables :

./tika-core/target/tika-core-0.6.jar
./tika-parsers/target/tika-parsers-0.6.jar

Par contre, tika-parser-0.6.jar requière un certain nombre de librairies tierces. Les récupérer est la troisième étape.

Etape 3 : Récupération des dépendances

On se place dans le répertoire des sources de tika-parser

cd tika-parsers

On demande à maven de récupérer les dépendances

mvn dependency:copy-dependencies

Les dépendances sont disponibles dans le sous-répertoire target/dependency et il s’agit de:

./target/dependency/asm-3.1.jar
./target/dependency/commons-compress-1.0.jar
./target/dependency/commons-logging-1.1.1.jar
./target/dependency/dom4j-1.6.1.jar
./target/dependency/fontbox-0.8.0-incubator.jar
./target/dependency/geronimo-stax-api_1.0_spec-1.0.1.jar
./target/dependency/hamcrest-core-1.1.jar
./target/dependency/jempbox-0.8.0-incubator.jar
./target/dependency/junit-3.8.1.jar
./target/dependency/log4j-1.2.14.jar
./target/dependency/metadata-extractor-2.4.0-beta-1.jar
./target/dependency/mockito-core-1.7.jar
./target/dependency/objenesis-1.0.jar
./target/dependency/pdfbox-0.8.0-incubating.jar
./target/dependency/poi-3.6.jar
./target/dependency/poi-ooxml-3.6.jar
./target/dependency/poi-ooxml-schemas-3.6.jar
./target/dependency/poi-scratchpad-3.6.jar
./target/dependency/tagsoup-1.2.jar
./target/dependency/xml-apis-1.0.b2.jar
./target/dependency/xmlbeans-2.3.0.jar

La solutions passe par une paramétrage du coté client pour envoyer des packets vides qui serviront à maintenir la connexion en vie.

Avec Putty : Onglet Connections > Seconds between keepalives : « 60″

Sous Linux : Dans « ~/.ssh/config » > « ServerAliveInterval 60″

Dans les cas ou cela est possible, cette configuration peut être réalisée coté serveur : dans « /etc/ssh/sshd_config » > « ClientAliveInterval 60″

Le but est de pouvoir développer sous Mac OX (Snow Leopard) des applications AMP (Apache / MySQL / PHP) et des applications Java (dont des servlets dans Tomcat). Dans cet article sont abordées les installations de Apache, PHP, MySQL, Java, Tomcat et Eclipse.

Xcode

C'est la première étape incontournable pour disposer d'un environnement de développement sous Mac OS. Xcode est disponible sur le DVD de Snow Leopard, mais la dernière version à jour est disponible gratuitement sur le site de Apple (http://developer.apple.com/products/membership.html). Xcode inclut les outils minimums pour créer et debugger des applications pour Mac (ou iPhone).

Java

Pour Java, il n'y a rien à faire puisque le JDK 1.6 est inclus dans Snow Leopard.

MySQL

Pour installé MySQL, j'ai suivi la procédure décrite dans cette page "Installing MySQL on Mac OS X". Je l'ai juste appliquée à une version 5.0.88.

A noter cette article également qui décrit en plus la création d'un user mysql "Compiling and Installing MySQL 5 on Mac OS X Leopard"

Apache

Comme pour Java, il n'y a rien à faire puisque Apache 2.2 est installé avec Snow Leopard (Partage web).

PHP

Apache est installé avec Snow Leopard donc en toute logique PHP l'est également (mais n'est pas actif dans Apache par défaut). Le problème (pas forcément pour tout le monde) est qu'il s'agit de la version 5.3 et que j'ai besoin de la version 5.2.x. Il faut donc downgrader PHP.

Activation de Php 5.3 dans Apache

Il suffit de décommenter la ligne suivante dans /etc/apache2/httpd.conf.

#LoadModule php5_module        libexec/apache2/libphp5.so

Downgrader Php en version 5.2.x

Pour cela, soit on utilise une distribution 5.2.x pour Mac OS toute prête, soit on compile soit même Php. Pour utiliser une distribution toutes prête de Php 5.2.9 pour Mac OS, on se rend sur le site de Marc Liyanage. Outre la page sur les distributions de Php pour Mac OS, ce site fournit des informations sur Mac OS en général, MySQL, Java et Perl.

J'ai choisi de compiler moi même Php afin de disposer d'une version à jour (5.2.11). Pour cela, je me suis principalement basé sur cet article "Reverting PHP 5.3 to 5.2.10 on Snow Leopard". Le seul changement que j'ai apporté à la procédure décrite concerne la configuration de la compilation de Php. J'ai utilisé cette ligne de commande afin d'activer entre autres l'option sockets.

./configure
    --prefix=/usr/local/php5
    --with-apxs2
    --enable-pdo
    --enable-ftp
    --enable-mbstring
    --enable-mbregex
    --enable-soap
    --enable-sockets
    --enable-gd-native-ttf
    --enable-cli
    --with-freetype-dir=/usr/local/lib
    --with-t1lib=/usr/local/lib
    --with-gd
    --with-zlib
    --with-jpeg-dir=/usr/local/lib
    --with-png-dir=/usr/local/lib
    --with-curl
    --with-mcrypt
    --with-pdo_mysql=/usr/local/mysql
    --with-mysql=/usr/local/mysql/
    --with-mysqli=/usr/local/mysql/bin/mysql_config
    --without-iconv

Je regrette de n'avoir pas réussi à installer et activer la librairie iconv à cause d'une erreur de compilation. Normalement, la solution est dans cette page, mais pour moi, cela n'a pas (encore) fonctionné.

Durant mes recherches, j'ai également trouvé ces articles intéressants :

• Enabling, Compiling and Installing PHP 5 on Mac OS X Leopard
• Installing AMP (Apache, MySQL, PHP) on Mac OS X 10.6 Snow Leopard

Note : pour l'installation de soap.so, voir http://www.bdoran.co.uk/2010/08/03/installing-php-soap-on-osx-leopard-10-6-4/

Tomcat

On trouve beaucoup d'articles décrivant l'installation de Tomcat sous Mac OS. Pour des raisons de compatibilités avec les serveurs Tomcat que je gère et pour lesquels je développe, je souhaite installer une version 5.5. Je me suis basé sur cet article : Apache Tomcat 5.5 Installation on Mac OS-X Leopard 10.5.x.

De mon coté, j'ai installé Tomcat dans /opt/apache-tomcat-5.5.28. J'ai également changer le port d'écoute de Tomcat de 8080 à 8180 comme sous Debian. La version de Java installée avec Snow Leopard est la 1.6 donc dans startup.sh, les variables JAVA_HOME et CATALINA_HOME sont les suivantes :

export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/
export CATALINA_HOME=/opt/apache-tomcat-5.5.28

Durant mes recherches, j'ai également trouvé ces articles intéressants :

• Installing Apache Tomcat 6 on Mac OS X Leopard
• Running Tomcat on Macintosh OS X

Dans ce dernier article est expliqué comment faire afin que Tomcat démarre automatiquement comme un demon. Il y plusieurs solutions et j'ai choisi la suivante :

1. Positionner les variables d'environnement JAVA_HOME et CATALINA_HOME au début du script /opt/apache-tomcat-5.5.28/bin/catalina.sh

2. Créer un fichier /Library/LaunchDaemons/org.apache.tomcat.plist qui contient ceci.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Disabled</key>
        <false/>
        <key>Label</key>
        <string>org.apache.tomcat</string>
        <key>ProgramArguments</key>
        <array>
                <string>/opt/apache-tomcat-5.5.28/bin/catalina.sh</string>
                <string>run</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
</dict>
</plist>

et lui affecter le bon propriétaire :

sudo chown root:wheel /Library/LaunchDaemons/org.apache.tomcat.plist

Le démarrage et l'arrêt manuel de Tomcat se font ainsi :

sudo launchctl load /Library/LaunchDaemons/org.apache.tomcat.plist

sudo launchctl unload /Library/LaunchDaemons/org.apache.tomcat.plist

Eclipse pour Java et Php

Pour l'installation de Eclipse, ma source d'informations est cet article Installing Eclipse Galileo on Mac OS X, mais on peut également regarder du coté de la distribution Pulse.

Java

La procédure est simple :

1. Sur la page de téléchargement de Eclipse,  récupérer la version Cocoa 32 bits de "Eclipse IDE for Java EE Developers" ou de "Eclipse IDE for Java Developers" et décompresser l'archive récupérée. Un répertoire "eclipse" est créé.

2. Créer un répertoire /Applications/Dev et y copier le répertoire "eclipse" issue de la décompression de l'archive.

Php

Pour la version Php de Eclipse (Eclipse for PHP Developers), la procédure est exactement la même. Avant de copier dans /Applications/dev le répertoire créé par la décompression de l'archive, je le renomme "eclipse php".

Xdebug pour Php

Pour Eclipse Php, il est nécessaire d'installer le composant de debuggage Xdebug.

Sur la page http://aspn.activestate.com/ASPN/Downloads/Komodo/RemoteDebugging/, on télécharge dans la section "Komodo 5.2 Remote Debugging Packages" le module "PHP Remote Debugging" pour Mac OS X. Une fois décompressé, l'archive contient la librairy xdebug.so pour différentes versions de Php.

Dans un terminal exécuter la commande qui suit (sur une seule ligne) en remplaçant les "x" par les valeurs correspondants à la version que vous aurez téléchargée :

sudo cp ~/Downloads/Komodo-PHPRemoteDebugging-5.2.x-xxxxx-macosx/5.2/xdebug.so
/usr/local/php5/include/php/ext/

Dans php.ini (/usr/local/php5/lib/php.ini), ajoutez les lignes suivantes à la fin du fichier :

zend_extension=/usr/local/php5/include/php/ext/xdebug.so

[Xdebug]
xdebug.remote_enable=1
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.remote_autostart=1
xebug.remote_handler=dbgp

Redémarrez Apache (Préférences Système -> partage -> partage web).

Sites utiles

• http://www.entropy.ch/home/welcome.php
• http://blog.zvikico.com/

Dans ce nouvel article, je vais expliquer plus en détail les points suivants :

• Le contenu de la distribution
• Les fichiers de configuration
• Comment gérer plusieurs indexes ?
• Comment gérer plusieurs applications ?

Le contenu de la distribution

Une fois récupérée et décompressée dans un répertoire, la distribution de Solr contient différents répertoires.

Mettre en place un environnement d’exécution de Solr à partir des éléments de la distribution est très simple. Il faut :

1. créer un  environnement d’exécution en copiant le répertoire « /example/solr », sous par exemple « /opt/solr » sous Linux ou « c:/solr » sous windows
2. copier le fichier solr.war contenu dans le répertoire webapps des exemples vers le répertoire approprié du serveur d’application (répertoire webapps par exemple pour Tomcat)
3. configurer le serveur d’application pour qu’il soit lancé avec la variable d’environnement solr.home.home pointant vers le répertoire  d’exécution (par exemple : -Dsolr.solr.home=/opt/solr) et le redémarrer

Dans le répertoire pointé par la variable d’environnement « solr.solr.home », on retrouve donc les répertoires « bin » (scripts utilitaires pour un environnement Linux), « conf » (fichiers de configuration) et « data » (y sera entre autres localisés l’index Lucene des données indexées).

Les fichiers de configuration

Les fichiers de configuration sont localisés dans le répertoire « /conf ». Il s’agit principalement de solrconfig.xml et schema.xml.

solrconfig.xml

Il s’agit du fichier qui contient l’essentiel des paramètres liés au fonctionnement de Solr et plus particulièrement des paramètres de l’API Lucene qu’utilise Solr (longueur maximale d’une champs, taille des buffer mémoire, fréquence de commit, …) . Ce fichier est très bien auto-documenté et fait l’objet d’un document a part entière dans le wiki Solr.

schema.xml

Il s’agit du fichier qui décrit comment seront indexées les données dans Solr. Il définit les types de données, les champs, les manipulations sur les données lors de l’indexation, les champs obligatoires, le champ de requête par défaut, …

Ce fichier est très bien auto-documenté et fait l’objet d’un document a part entiere dans le wiki Solr.

Exemple de déclaration d’un type

<fieldType name=”string” class=”solr.StrField” sortMissingLast=”true” omitNorms=”true”/>

Ce type a pour nom « string », il sera pris en charge lors de l’indexation par la classe « solr.StrField », lors d’un tri du résultat sur ce champ, les documents ne le possédant pas seront positionnés en dernier (sortMissingLast= »true ») et lors de l’indexation les informations de normalisation basées sur la taille du champ seront calculées et stockées (omitNorms= »true »).

Exemple de déclaration d’un champ

Les données indexées dans Solr par le service d’indexation sont contenues dans un datagramme de type XML. Lorsque Solr traite ce datagramme, il rapproche le nom de chaque élément XML avec le nom d’un champ. Il manipule alors la donnée associé à cet élément comme cela est défini par la définition du champ.

<field name=”word” type=”string” indexed=”true” stored=”true”/>

Ce champ est du type « string » (donc il hérite des propriétés de ce type). Il est indexé (donc les recherches peuvent porter sur son contenu) et les données de ce champs sont stokées (donc elles peuvent être récupérées au moment de l’affichage d’une liste de résultats par exemple).

D’autres paramètres importants peuvent également être définis lors de la déclaration d’un champ. Il s’agit de la méthode d’analyse lors de ‘indexation ou de la recherche. La méthode d’analyse permet de définir comment seront traitées les données du champ, à savoir son mode de découpage en mots (tokenizer) et les filtres qui lui seront appliqués (filter). Les filtres permettent par exemple de supprimer les mots vides, de mettre tous les mots en minuscule, de convertir les mots accentués en leurs équivalents sans accent, …

Exemple de déclaration d’un champ dynamique

Une déclaration de champ dynamique permet d’associer un traitement à des éléments du datagramme XML même si ces derniers ne sont pas spécifiquement déclarés comme champs.

<dynamicField name=”*_s”  type=”string”  indexed=”true”  stored=”true”/>

Tout élément du datagramme XML dont le nom se termine par « _s », est considéré comme un élément de nom « string ».

Comment gérer plusieurs indexes ?

Par défaut, une instance Solr ne peut manipuler qu’un index. Comment faire si mon application doit permettre l’indexation de plusieurs types de données comme par exemple un annuaire de personnes et les messages d’un forum de discussion ?

Jusqu’à la version de 1.2 de Solr, il existait 2 solutions : associer un type à chaque document dans l’index (personne, message, …) ou utiliser plusieurs webapps dans le serveur J2EE et les faire pointer vers des environnements différents (-D=solr.solr.home=…). L’association d’un type à chaque document permet lors de la recherche de filtrer la liste de résultats en se limitant aux documents d’un ou plusieurs types. Utiliser plusieurs webapps permet d’utiliser un index distinct pour chaque type de documents.

Avec la version 1.3 de Solr est apparue la notion de « SolrCore » multiples. Un « SolrCore » est un environnement complet Solr (configuration et index) qui est exécuté par une webapps du serveur j2EE. Il est donc possible au moyen d’une seule webapps Solr de gérer plusieurs « SolrCore ». les SolrCore sont déclarés dans un fichier XML « solr.xml » localisé dans le répertoire solr.solr.home associé à la webapp.

Exemple d’un environnement mono-core

solr.solr.home=/opt/solr

Les répertoires d’installation sont organisés comme ceci :

/opt
    /solr
        /bin
        /conf
        /data
        /webapps
            solr.war

Pour un paramétrage de Tomcat au moyen de JNDI, on place dans le répertoire conf/Calalina/localhost de Tomcat, le fichier solr.xml suivant :

<Context docBase="/opt/solr/webapps/solr.war" debug="0" crossContext="true" >
    <Environment
        name="solr/home"
        type="java.lang.String"
        value="/opt/solr/" override="true" />
</Context>

Les urls d’accès à l’administration et aux web service Solr sont :

Exemple d’un environnement multi-core

solr.solr.home=/opt/solr

Les répertoires d’installation sont organisés comme ceci :

/opt
    /solr
        solr.xml
        /core0
            /bin
            /conf
            /data
        /core1
            /bin
            /conf
            /data
        /webapps
            solr.war

Pour un paramétrage de Tomcat au moyen de JNDI, on place dans le répertoire conf/Calalina/localhost de Tomcat, le fichier solr.xml suivant :

<Context docBase="/opt/solr/webapps/solr.war" debug="0" crossContext="true" >
    <Environment
        name="solr/home"
        type="java.lang.String"
        value="/opt/solr/" override="true" />
</Context>

Dans le répertoire pointé par solr.solr.home, on place de féchier solr.xml suivant :

<solr persistent="true" sharedLib="lib">
    <cores adminPath="/admin/cores">
        <core name="core0" instanceDir="core0" />
        <core name="core1" instanceDir="core1" />
    </cores>
</solr>

Les urls d’accès à l’administration et aux web service Solr des cores 0 et 1 sont :

Comment gérer plusieurs applications ?

Imaginons que vous souhaitez indexer des données issues de différentes applications, pour l’exemple, un outil de gestion de contenu (ECM) et un forum de discussion. Chacune de ces applications nécessitant l’indexation de 2 types de données totalement différentes, pour l’exemple, des utilisateurs et des documents (ECM) ou des messages (forum).

Dans ce cas, je propose d’utiliser une webapp par application et un core par type de données.

On a donc un environnement comme celui-ci :

solr.solr.home=/opt/solr

Les répertoires d’installation sont organisés comme ceci :

/opt
    /solr
        /ecm
            solr.xml
            /utilisateurs
                /bin
                /conf
                /data
            /documents
                /bin
                /conf
                /data
        /forum
            solr.xml
            /utilisateurs
                /bin
                /conf
                /data
            /messages
                /bin
                /conf
                /data
        /webapps
            solr.war

Pour un paramétrage de Tomcat au moyen de JNDI, on place dans le répertoire conf/Calalina/localhost de Tomcat, le fichier ecm.xml suivant :

<Context docBase="/opt/solr/webapps/solr.war" debug="0" crossContext="true" >
    <Environment
        name="solr/home"
        type="java.lang.String"
        value="/opt/solr/ecm" override="true" />
</Context>

et le fichier forum.xml suivant :

<Context docBase="/opt/solr/webapps/solr.war" debug="0" crossContext="true" >
    <Environment
        name="solr/home"
        type="java.lang.String"
        value="/opt/solr/forum" override="true" />
</Context>

Dans le répertoire « /opt/solr/ecm », on place de féchier solr.xml suivant :

<solr persistent="true" sharedLib="lib">
    <cores adminPath="/admin/cores">
        <core name="utilisateurs" instanceDir="utilisateurs" />
        <core name="documents" instanceDir="documents" />
    </cores>
</solr>

Dans le répertoire « /opt/solr/forum », on place de féchier solr.xml suivant :

<solr persistent="true" sharedLib="lib">
    <cores adminPath="/admin/cores">
        <core name="utilisateurs" instanceDir="utilisateurs" />
        <core name="messages" instanceDir="messages" />
    </cores>
</solr>

Les urls d’accès à l’administration et aux web service Solr de l’application ECM sont :

Les urls d’accès à l’administration et aux web service Solr de l’application Forum sont :

Sous Linux, une optimisation peut être de factoriser le répertoire « bin » de chaque core car il contient exactement les mêmes scripts. On place un répertoire « bin » dans « /opt/solr » et dans chaque core, on créer un lien symbolique nommé « bin » et qui pointe sur « /opt/solr/bin ».

Pour synthétiser les différents cas de figure lors du choix d’une configuration de Solr, voici un tableau récapitulatif.