Dieser Artikel ist ein Nachdruck dessen, was auf Blog veröffentlicht wurde.
Die Atlassian Plug-In-Entwicklungsplattform verwendet eine Vielzahl von Java-Frameworks, von denen einige üblich sind. Dieses Mal möchte ich ein Atlassian-ähnliches Webframework vorstellen, das mit diesen Frameworks erstellt wurde. Die Arbeit ist auf GitHub veröffentlicht.
Ziel dieses Webframeworks ist es, "das allgemeine Java-Framework von der Atlassian-Plugin-Entwicklungsplattform zu trennen". Die folgenden Effekte werden dadurch erzielt.
Dieses Webframework besteht aus den folgenden Frameworks.
Java EE
Java EE Beans, JSP und Servlet werden zur Realisierung des MVC-Modells verwendet. Die Atlassian-Plug-In-Entwicklungsplattform verwendet auch ein Java-Framework namens WebWork als MVC-Modell, die Version unterscheidet sich jedoch je nach Produkt (JIRA 1.x. -plattform / jira-architektur / jira-technische-übersicht / jira-webwork-aktionen), andere 2.x) und schließt aus, dass sie beim erstellen von aktionen ihre eigene abstrakte klasse erben muss. Dieses WebWork ist übrigens seit Version 2.2 in Struts2 integriert.
Spring DI
Die Feder DI wird für die Injektion der Komponentenabhängigkeit verwendet. Der Grund, warum in der Komponentendefinition keine Annotation verwendet wird, ist die Verwendung von "atlassian-plugin.xml" (Spring's "applicationContext". Dies liegt daran, dass es in (entsprechend xml`) definiert werden soll. Bei vielen Plugins scheint die Methode zum Definieren in "atlassian-plugin.xml" üblich zu sein, und mein Projekt übernimmt auch diese Methode. Die Autowired-Annotation wird jedoch aufgrund eines Spezifikationsproblems zum Einfügen in Module wie Servlet- und REST-Ressourcen verwendet.
Jersey
Jersey wird verwendet, um RESTful-Webdienste bereitzustellen. Da Daten ausschließlich im Json-Format ausgetauscht werden, sind sie für Json verfügbar. In der Atlassian-Plug-In-Entwicklung ist die Erweiterbarkeit vorhandener Bildschirme schlecht, und insbesondere kann die gesamte durch Bildschirmoperationen ausgelöste Datenverarbeitung nur über die REST-API ausgeführt werden. Daher wird diese Funktion häufig verwendet, und ich halte es für wichtig, dass sie separat von der Atlassian-Plug-In-Entwicklungsplattform entwickelt werden kann.
ActiveObjects
Ich verwende ActiveObjects als ORM-Tool. ActiveObjects verwendet Kamelfälle als Namenskonventionen für Tabellen und Felder, während Atlassian [obere Schlangenfälle] verwendet (https://developer.atlassian.com/docs/atlassian-platform-common-components/active-objects/). Das Entwickeln Ihres Plugins mit aktiven Objekten / aktiven Objekten (FAQ / Spaltennamen) wird übernommen. Daher entspricht das Framework auch den Atlassian-Spezifikationen. Der Atlassian-Spezifikationsnamenkonverter befindet sich unter dem Paket net.java.ao.atlassian.
Velocity
Ich benutze Velocity als Template-Engine. Ich persönlich bevorzuge Velocity gegenüber JSP, da es in einer modernen Syntax beschrieben werden kann. Das Atlassian-Plug-In wird im Allgemeinen in Kombination mit WebWork verwendet. Da WebWork jedoch aufgrund des oben genannten Komforts ausgeschlossen ist, wird es in Servlet verwendet.
Durch die Verwendung dieses Frameworks scheint die Datenverarbeitung über die REST-API unverändert behandelt zu werden. Da die Entwicklung mit Modulen mit hoher Nachfrage wie Ereignis-Listenern und Workflows jedoch nicht möglich ist, ist es meiner Meinung nach effizienter, Mitglieder zu schulen, damit sie Atlassian-Plug-Ins entwickeln können.