Silverpeas » Silverpeas Setup

Miguel, ce point est assez urgent, car chaque install se retrouve vérolé par le clean install

Le problème vient qu'il existe deux jackrabbit-rar : un qui vient de Silverpeas, l'autre de ... Apache.
J'ai mis du temps à cerner ce soucis et encore plus à trouver la raison et le moyen d'éviter ce problème.

En fait, pour une raison que je ne m'explique pas, lorsque Gradle, qui est utilisé comme colonne vertébrale de l'installateur, résout la dépendance jackrabbit-jca de Silverpeas déclarée dans le silverpeas-assembly, il récupère comme dépendance transitive le jackrabbit-jca d'Apache sous forme de RAR ! Or ce dernier n'est pas déclaré comme dépendance dans le projet Silverpeas Jackrabbit JCA. C'est du jar (et non du rar) de jackrabbit-jca d'Apache que le projet dépend. Et même si ce dernier est déclaré dans un scope runtime (ce qui signifie qu'il ne devrait pas être récupéré par transitivité), Gradle récupère tout de même le rar de jackrabbit-jca d'Apache. La conséquence de ceci est que lorsque l'installateur traite les rars, comme ces deux archives ont le même nom, ben l'un des deux écrase l'autre. Jusqu'à présent, ce fut celui de Silverpeas qui a été traité le dernier et donc c'est lui qui écrasait celui d'Apache. Le problème était donc caché. Sauf que ... ben des fois ça coince et c'est l'inverse : c'est la version d'Apache qui écrase celle de Silverpeas et ces derniers temps ce soucis est devenu plus fréquent.

Désormais, une instruction d'exclusion de jackrabbit-jca d'Apache a été ajoutée dans le silverpeas-assembly de la version 6.3.4-SNAPSHOT (donc prochaines versions de build).

Pour les versions existantes, une astuce est d'écraser l'archive $SILVERPEAS_HOME/deployments/jackrabbit-jca.rar par celle contenue dans le dossier ~/.gradle/caches/modules-2/files-2.1/org.silverpeas.jcr/jackrabbit-jca/<version>/<hash>/