Quarkus basiert in seinem Kern lediglich auf einem einfachen Komponentensystem. Jede weitere Funktionalität ist in einer eigenen Erweiterung gekapselt, die bei Bedarf hinzugefügt werden kann. Dies ermöglicht es Entwicklern, nur die benötigten Komponenten in ihre Anwendungen zu integrieren, was zu schlankeren und effizienteren Anwendungen führt.
Um eine eigene Quarkus Extension zu erstellen, können Sie das Maven-Archetype für Quarkus Extensions verwenden. Dieses Archetype stellt die grundlegende Struktur für die Erweiterung bereit.
$ mvn io.quarkus.platform:quarkus-maven-plugin:3.29.4:create-extension \
-N \
-DgroupId=de.gedoplan.showcase \
-DextensionId=central-registry-extension \
-DwithoutTests
Das Projekt besteht aus einem Deployment- und einem Runtime-Modul.
Das Runtime-Modul (central-registry-extension) ist eine ganz normale Quarkus Erweiterung und kann entsprechend weitere Erweiterungen beinhalten. Das Deployment-Modul (central-registry-extension-deployment) hat eine Abhängigkeit zum Runtime-Modul und kann ebenfalls weitere Erweiterungen enthalten.
<dependency>
<groupId>de.gedoplan.showcase</groupId>
<artifactId>central-registry-extension</artifactId>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-arc-deployment</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-undertow-deployment</artifactId>
</dependency>
Quarkus wurde mit der Idee geschaffen die Speicher- und Ressourcennutzung der Anwendung zu verringern und damit auch einen möglichst schnellen Start der Anwendung zu ermöglichen. Daher wird in einer Quarkus Anwendung möglichst viel bereits zur Build-Zeit erledigt. In dieser Weise funktionieren auch die Quarkus Extensions. Im Deployment-Modul gibt es sogenannte Build-Schritte, in denen man sich in den Build-Prozess einklinken kann. In ihnen werden sogenannte Build-Items erzeugt, die in einen hocheffizienten Bytecode umgewandelt werden.
Möchte man beispielsweise eigene CDI-Beans integrieren, so kann man das über das AdditionalBeanBuildItem erreichen.
@BuildStep
AdditionalBeanBuildItem registerStartupListener() {
return AdditionalBeanBuildItem.builder()
.addBeanClass(CentralRegistryClient.class)
.addBeanClass(StartupListener.class)
.setUnremovable()
.build();
}
Diese zusätzlichen Beans sind wiederum im Runtime-Modul implementiert. Warum macht man sich dann die Mühe diese Beans über eine Extension einzubinden? Das Ganze würde ja auch funktionieren, wenn man statt einer Extension einfach ein Jar mit diesen Beans in seine Anwendung einbindet. Die Antwort lautet ja, aber dadurch erreicht man nicht die zuvor beschriebene Optimierung während der Build-Zeit. Quarkus kann durch die Implementierung einer Extension entsprechenden Bytecode bereitstellen, der eine optimale Integration meiner Implementierung ermöglicht.
Da eine tiefer gehende Erklärung der Mechanismen innerhalb von Quarkus den Rahmen dieses Beitrags sprechen würden, habe ich ein ausführliches Beispiel einer Quarkus Extension auf Github bereitgestellt: https://github.com/GEDOPLAN/quarkus-custom-extensions
