SAL (couche d’accès partagés en français) fournit un ensemble d’API, permettant de réaliser les tâches communes à tous plugins, indépendamment de l’application Atlassian. Quelque soit le plugin que l’on développe, qui ne veut pas persister sa configuration dans l’application ? Avoir des labels internationalisés ? Ces tâches archi-communes, on parle ici de « services » sont malheureusement gérées différemment pour chaque produit. SAL permet d’unifier tout cela, et de simplifier grandement la vie du développeur. Il est évident que pour des plugins x-produit (qui s’installe aussi bien sur JIRA que sur Confluence par exemple), SAL devient indispensable.
Pour la majorité des plugins (mono-application). Les développeurs ont le choix : utiliser directement l’API du produit ou s’appuyer sur SAL. L’utilisation de SAL quand elle est possible est à privilégier. Pourquoi réécrire sans arrêt les mêmes choses ? Voilà une API qui va évoluer, s’améliorer, nous éviter les pièges de tels ou tels framework utilisés par telles applications, prendre en compte tels spécificités de JIRA ou Confluence. Bref, il n’y a plus à hésiter…
Voici les services les plus communs pris en compte par SAL :
- La planification des tâches
- L’internationalisation des labels (utilisé dans les Gadget)
- La persistance de configuration du plugin.
- L’upgrade d’un plugin.
Rien ne vaut l’exemple pour illustrer un propos…
La persistance de la configuration d’un plugin :
SLA fournit un objet PluginSettings qui est obtenu depuis l’interface PluginSettingsFactory comme montré ci-après :
La classe concrète de la fabrique : JiraPluginSettingsFactory ou ConfluencePluginSettingsFactory… sera choisie en fonction du produit en cours d’utilisation (c’est lors de l’injection du component que cela se decidera). Chaque produit va donc gérer ces properties à sa façon, JIRA utilisera le framework propertySet, Confluence s’appuiera lui sur Bandana, mais tout ceci sera restera transparent pour nous. Un même code pour un plugin x-produit permettra de persister la configuration d’une manière ou d’une autre en fonction du produit sur lequel on installe le plugin.
Voici le diagramme des classes associés :
Utilisation des service SAL
Il faut :
1- Déclarer in component-import dans le atlassian-plugin.xml du plugin...
key=”userManager”
interface=”com.atlassian.sal.api.user.UserManager” />
2- Inclure dans le pom.xml les dependances à SAL:
<groupId>com.atlassian.sal</groupId>
<artifactId>sal-api</artifactId>
<version>2.0.0</version>
<scope>provided</scope>
</dependency>
Attention à la version en fonction du produit cible, il peut y avoir un impact.
Pour aller plus loin :
http://confluence.atlassian.com/display/SAL/Shared+Access+Layer+Developer+Documentation
http://confluence.atlassian.com/display/SAL/SAL+Version+Matrix
