Silverpeas » Silverpeas Core

Avec Silverpeas 6, Silverpeas Core est désormais découpé comme suit :

• core-configuration : regroupe toute la configuration du cœur de Silverpeas 6 ainsi que les instructions de migration de base de données pour le cœur. (Anciennement config-core dans Silverpeas 5.)
• core-api : c'est l'API métier de Silverpeas Core. Y sont définis les API des différents moteurs qui constituent le cœur collaboratif de Silverpeas. C'est de cette bibliothèque que doivent dépendre tout projet, tout composant Silverpeas.
• core-test : ensemble de classes qui permettent d'écrire plus facilement un test unitaire ou un test d'intégration et qui s'appuie sur core-api. Seule une version de BeanContainer dédiée aux tests unitaires est fournie pour rendre effective les appels au ServiceProvider dans les codes testés ; les interfaces définis dans core-api doivent être singés (mocks) pour rester dans l'esprit du principe des tests unitaires. Les tests d'intégration reposent sur Arquillian pour les dérouler directement dans le conteneur JEE cible de Silverpeas (Wildfly).
• core-library : l'implémentation de l'API fournie par core-api. Cette bibliothèque ne devrait pas être utilisée directement par les projets ou composants Silverpeas. (Anciennement lib-core dans Silverpeas 5.)
• core-services : ensemble de services transverses reposant sur l'API et qui ajoutent une fonctionnalité particulière et transverse à Silverpeas. Les projets et composants Silverpeas peuvent reposer sur ces derniers pour étendre leurs fonctionnalités. Ces services comprennent à la fois leur API et son implémentation. (Anciennement services-core dans Silverpeas 5.)
• core-web : c'est l'API Web de Silverpeas 6. Y sont définis l'architecture et le moteur Web utilisés par Silverpeas et sur lesquels doivent se reposer toutes applications Silverpeas pour assurer l'homogénéité de son IHM et de son fonctionnement ; on y retrouve le framework MVC maison et le framework REST. (Anciennement web-core dans Silverpeas 5).
• core-web-test : c'est le pendant de core-test mais pour core-web-api. Il permet de faciliter l'écriture de tests d'intégration pour le Web.
• core-war : l'IHM de Silverpeas 6. (Anciennement war-core dans Silverpeas 5.)

Une grande étape a été accomplie pour séparer les API de leur(s) implémentation(s) dans Silverpeas Core. Toutefois, cette séparation n'est pas complète. Elle devra donc se poursuivre au fur et à mesure des évolutions dans la mesure du possible.
En effet, actuellement, un historique fait que des API de Silverpeas sont encore dans l'implémentation (core-library ou dans core-services) et des questions sur la valeur ajoutée, donc sur l'existence, de core-services restent en suspens :

• parce que des API sont étroitement et fortement couplés soit avec leurs implémentations, soit avec l'implémentation d'autres API ou sur du code tiers définis dans core-library font qu'elles ne peuvent être déplacées dans core-api sans un travail de refactoring conséquent.
• la présence de core-services fait débat : est ce que l'approche qui sépare les fondations du cœur de Silverpeas (core-api et son implémentation dans core-library) de celui des services transverses supplémentaires (core-services) est toujours d'actualité ? L'avantage d'une telle approche est qu'il permet de séparer distinctement ce qui fait le coeur même de Silverpeas (le bus collaboratif avec ses objets métiers) des fonctionnalités de base de Silverpeas. Or, actuellement, au regard de cette séparation, du code dans core-api ou core-library devraient être dans les services (les attachments par exemple). Ensuite, cette séparation peut conduire à rendre plus complexe la découpe en API et implémentation (il ne devrait pas avoir de core_api et de core-library mais un projet core-bus qui comprendrait les deux sous-projets précédent). Pour finir, avec l'évolution de Silverpeas, la frontière entre ce qui fait le bus collaboratif (les fondations) de Silverpeas et les services transverses sont devenu flous au point que leur séparation soulève plus de questions qu'elle n'en résout (cf. les attachements par exemple ou encore la nouvelle API agenda). La question est donc de savoir si on maintient core-services et par conséquent la distinction entre le bus et les services transverses ou si, in fine, on l'abandonne et les services devront se répartir entre core-api et core-library. Ce dernier choix permettrait de simplifier la gestion du code au détriment d'une lourdeur accrue de core-api et core-library ; une lourdeur qui pourrait être acceptable puisque de toute manière les services sont tous inclus dans le portail Silverpeas et que ce dernier constitue l'environnement d'exécution des applications Silverpeas.

Avec Yohann on est toujours à discuter du dernier point. Actuellement, on pencherait pour répartir le code de core-services entre core-api et core-library.