Cet article est une réimpression de ce qui a été publié sur Blog.
La plate-forme de développement de plug-ins Atlassian utilise une variété de frameworks Java, dont certains sont communs. Cette fois, je voudrais présenter un framework Web de type Atlassian créé à l'aide de ces frameworks. Le travail est posté sur GitHub.
Le but de ce framework web est de "séparer le framework Java général de la plateforme de développement de plugins Atlassian". Les effets suivants sont obtenus par ceci.
Ce framework Web comprend les frameworks suivants.
Java EE
Java EE Beans, JSP et Servlet sont utilisés pour réaliser le modèle MVC. La plate-forme de développement de plug-ins Atlassian utilise également un framework Java appelé WebWork comme modèle MVC, mais la version diffère selon le produit (JIRA 1.x. -platform / jira-architecture / jira-technical-overview / jira-webwork-actions), others 2.x), et l'exclut d'avoir à hériter de sa propre classe abstraite lors de la création d'actions. D'ailleurs, ce WebWork est intégré à Struts2 depuis la version 2.2.
Spring DI
Spring DI est utilisé pour l'injection de dépendances de composants. La raison pour laquelle aucune annotation n'est utilisée dans la définition du composant est d'utiliser ʻatlassian-plugin.xml (ʻapplicationContext de Spring.] Sans utiliser [Atlassian Spring Scanner](https://bitbucket.org/atlassian/atlassian-spring-scanner). C'est parce qu'il est censé être défini dans (correspondant à xml). Pour autant que je puisse voir de nombreux plugins, il semble que la méthode de définition dans ʻatlassian-plugin.xml` soit courante, et mon projet adopte également cette méthode. Cependant, l'annotation Autowired est utilisée pour l'injection dans des modules tels que les ressources Servlet et REST en raison d'un problème de spécification.
Jersey
Jersey est utilisé pour fournir des services Web RESTful. Étant donné que les données sont échangées exclusivement au format Json, elles sont définies pour être disponibles pour Json. Dans le développement de plug-ins Atlassian, l'extensibilité des écrans existants est médiocre, et en particulier, tous les traitements de données déclenchés par des opérations d'écran ne peuvent être effectués que via l'API REST. Par conséquent, cette fonction est fréquemment utilisée et je pense qu'il est important qu'elle puisse être développée séparément de la plate-forme de développement de plug-in Atlassian.
ActiveObjects
J'utilise ActiveObjects comme outil ORM. ActiveObjects utilise des cas de chameau comme conventions de dénomination de table et de champ, tandis qu'Atlassian utilise des cas de serpent supérieurs. développer-votre-plugin-avec-objets-actifs / faq-objets-actifs / noms-colonnes) est adopté. Par conséquent, le cadre est également conforme aux spécifications Atlassian. Le convertisseur de nom de spécification Atlassian se trouve sous le package net.java.ao.atlassian.
Velocity
J'utilise Velocity comme moteur de modèle. Personnellement, je préfère Velocity à JSP car il peut être décrit dans une syntaxe moderne. Le plug-in Atlassian est généralement utilisé en combinaison avec WebWork, mais comme WebWork est exclu en raison de la commodité mentionnée ci-dessus, il est utilisé dans Servlet.
En utilisant ce framework, il semble que le traitement des données via l'API REST puisse être géré tel quel. Cependant, il n'est pas possible de gérer le développement en utilisant des modules à forte demande tels que les écouteurs d'événements et les workflows, je pense donc qu'il est plus efficace d'éduquer les membres afin qu'ils puissent développer des plug-ins Atlassian.