When you develop an application composed of several components, it is frequent to want to share some code in an external library, for example via an external JAR integrated as a dependency of your components.<\/p>\n
Quarkus is an extension framework, each extension it offers allows to integrate a technology (BDD client, ORM framework, …) to Quarkus, so it can be configured globally, used easily via CDI (dependency injection), work with GraalVM, …<\/p>\n
Quarkus has its own build system, via its Maven or Gradle plugin, which allows to deport to build time the bootstarting of your application via an extension. So it would be a natural fit to share the common code to several components developed with Quarkus via an extension.<\/p>\n
But creating an extension is complicated and requires advanced skills on the internal functioning of Quarkus. Except if you need advanced features as described in the extension writing guide<\/a>, it is often enough to create a “standard” JAR with the technique described in the rest of this post.<\/p>\n So we will create a standard JAR via a classical Maven module; the only specificity is that for the code of this JAR to be “discovered” by Quarkus, it must be indexed by Jandex. Jandex<\/a> is used by Quarkus to discover your application’s code at build time via indexing your application’s code, instead of discovering it at runtime via more standard mechanisms such as classpath scanning and reflection.<\/p>\n Quarkus will automatically index the code of our application, but not of its dependencies, so we will add the Maven Jandex plugin to create an index of the code of our common JAR when packaging it by Maven:<\/p>\n Now, we will be able to write code that will be discovered by Quarkus: for example, provide CDI beans that we can then inject into our application code.<\/p>\n Let’s take for example the creation of a client for Consul based on the Consul Client for Java<\/a>.<\/p>\n The first step is to create a class representing the client’s configuration, for this we will use the Config Mapping<\/a> principle: an interface that represents your configuration items:<\/p>\n This class can have a default configuration that is found in the We can then write a CDI producer based on your configuration class to produce a Consul client as a CDI bean that can be injected into your application code:<\/p>\n Once this JAR is packaged, we just need to add it as a dependency to our application, and then set the properties that need to be set in our Finally, we can inject the Consul client bean into our application code, here a REST endpoint (JAX-RS):<\/p>\n Here, the Consul client is injected into our JAX-RS endpoint, and then used in the I mentioned it at the beginning of the article, one of the most classic features provided by an extension, is the support of the GraalVM native image compilation. Even if you can do a more advanced configuration via an extension, you can still do it via a simple common JAR providing a list of classes to register for reflection via the @RegisterForReflection<\/code>code>@RegisterForReflection<\/code<\/a> annotation.\nHere is an example that register 3 dummy classes for reflection (this step is not necessary for our Consul client):<\/p>\n One can also directly provide standard GraalVM configurations via standard configuration files<\/a> or via substitutions<\/a>.<\/p>\n And that’s how not<\/strong> to create a Quarkus extension.\nIf you insist on wanting to create one, you can watch my talk on done at Devoxx FR 2021<\/a> on the subject ;) (french only).<\/p>","protected":false},"excerpt":{"rendered":" When you develop an application composed of several components, it is frequent to want to share some code in an external library, for example via an external JAR integrated as a dependency of your components. Quarkus is an extension framework, each extension it offers allows to integrate a technology (BDD client, ORM framework, …) to Quarkus, so it can be configured globally, used easily via CDI (dependency injection), work with GraalVM, … Quarkus has its own build system, via its…\n\n \n \n org.jboss.jandex\n jandex-maven-plugin\n 1.2.1\n \n \n make-index\n \n jandex\n \n \n \n \n \n\n<\/pre>\n
\n@ConfigMapping(prefix = \"consul\")\ninterface ConsulConfig {\n String host();\n int port();\n}\n<\/pre>\nMETA-INF\/microprofile.properties<\/code> file, this file is automatically discovered by the Quarkus configuration system in each JAR of the classpath.\nYou can override this configuration if necessary in the application.properties<\/code> file of your application.<\/p>\n\nconsul.host=localhost\nconsul.port=8500\n<\/pre>\n
\n@ApplicationScoped \/\/ 1\npublic class ConsulClientProducer {\n @Inject ConsulConfig config; \/\/ 2\n\n @Produces \/\/ 3\n @ApplicationScoped \/\/ 4\n public Consul consulClient() {\n HostAndPort hostPort = HostAndPort.fromParts(config.host(), config.port());\/\/ 5\n return Consul.builder().withHostAndPort(hostPort).build(); \/\/ 6\n }\n}\n<\/pre>\n@Produces<\/code>.<\/li>\n\n@ApplicationScoped<\/code>.<\/li>\n\napplication.properties<\/code> file (it will override the one in the microprofile.properties<\/code> file from the common JAR) :<\/p>\n\nconsul.host=my.consul.host\n<\/pre>\n
\n@Path(\"\/\")\npublic class HelloConsulEndpoint {\n @Inject Consul consulClient;\n\n @GET\n public String getFromConsul() {\n KeyValueClient kvClient = consulClient.keyValueClient();\n return kvClient.getValueAsString(\"foo\").get(); \n }\n}\n<\/pre>\ngetFromConsul()<\/code> method to retrieve a key value from Consul and return it to the user.<\/p>\n\n@RegisterForReflection(targets={ FirstClass.class, SecondClass.class, ThridClass})\npublic class NativeImageReflectiveConfiguration {\n}\n<\/pre>\n