Lors de nos développements, nous reposons beaucoup sur des projets
externes qui nous fournissent énormément de services utiles. Dans un
récent projet, nous avons eu besoin de faire fonctionner Neo4j
conjointement à ElasticSearch. Jusqu’ici, aucun soucis n’est à
déplorer, mais nous avions une exigence particulière : il fallait
que l’application puisse démarrer automatiquement un serveur Neo4J
ainsi qu’un serveur ElasticSearch sur les postes de développements
(ainsi que pour les tests d’intégration).
Problème existant
Les deux outils que nous utilisons se basent sur Apache Lucene pour
toute la partie indexation et accès aux données. Mais, et c’est là
que le problème se situe, ils n’utilisent pas les mêmes versions de
Lucene.
<!-- Extrait du pom d'ElasticSearch -->
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-core</artifactId>
<version>4.9.0</version>
<scope>compile</scope>
</dependency>
<!-- Extrait du pom de Neo4j -->
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-core</artifactId>
<version>3.6.2</version>
</dependency>
ElasticSearch utilise la version 4.9.0, alors que Neo4J utilise la
version 3.6.2. Ainsi, en fonction du bon vouloir du
Classloader qui sera utilisé par l’application, il se
peut qu’ElasticSearch ou Neo4J refuse de fonctionner. La difficulté
pour comprendre et détecter le problème est qu’il se manifeste
souvent par un obscur NoClassDefFoundError ou
NoSuchMethodError qui n’est pas des plus explicites
(d’autant plus lorsque notre IDE nous montre une version qui
contient ledit symbole non trouvé).
Solution de contournement
Le conflit est assez simple à contourner une fois qu’on a compris ce
qui se passe. En fait, il y a deux classes portant le même nom dans
les classes chargées, par exemple org.lucene.MaClass,
l’une effaçant l’autre aux yeux du ClassLoader. Une
pratique courante est de renommer (ou relocate) le package de base
d’une bibliothèque utilisée et de l’inclure dans le fichier de
package du projet, le plugin maven-shade est conçu dans
cette optique. Le choix fait est de renommer la dépendance Lucene
dans Neo4J pour notre part, ainsi, nous avons forké le projet et
configuré le plugin shade pour qu’il inclue le contenu
de la dépendance d’Apache Lucene et qu’il fasse le renommage de
org.apache.lucene en
shaded.org.apache.lucene.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<createDependencyReducedPom>true</createDependencyReducedPom>
<artifactSet>
<includes>
<include>org.apache.lucene:*</include>
</includes>
</artifactSet>
<relocations>
<relocation>
<pattern>org.apache.lucene</pattern>
<shadedPattern>shaded.org.apache.lucene</shadedPattern>
</relocation>
</relocations>
</configuration>
</execution>
</executions>
</plugin>
Déploiement et nommage
Pour ne pas polluer les dépôts, le numéro de version modifié a été
postfixé par -shaded. Le déploiement a été fait sur un
dépôt Maven qui est en fait un simple repository Github. Le commit
correspondant à cette modification
est consultable ici.
