At work I'm splitting up an existing Quarkus application into several modules:
- three "application modules"
A,BandCcontaining controllers/API endpoints - a single
sharedmodule for shared code and database access - a
deploymentmodule that bundles all modules together for deployment
The idea is that I can combine different versions of A, B and C in production (perhaps I am not ready to deploy my changes to A to production, even though I want to deploy the changes in B now).
Strictly speaking, the quarkus-maven-plugin is only required for the deployment module because that is the only module that I will want to run as a Quarkus application.
However, because each of the application modules is responsible for a set of endpoints, it seems logical to put the integration tests (@QuarkusTests) for those in the application modules themselves. However, this will require the quarkus-maven-plugin for each of the modules, only for the purpose of being able to run the integration tests.
Are there any adverse effects of doing this?
An alternative I'm considering is to put the integration tests for each application module in seperate modules (A-tests, B-tests and C-tests) and include the quarkus-maven-plugin in those. Is that better?
It can be solved but it is not straight forward.
The following tasks have to be done
At first, I have to clarify this
One of the most important concept of Quarkus to favor build time work over runtime. That's why
quarkus-maven-plugindoes much more than just build deployable artifact. So, this plugin is always required by each module wheter that module is deployable or not.Create Multi Module Maven project
Let's say there are three modules (four
pom.xmlfiles)*-parent - An aggregator which contains common settings, plugin templates, dependencies used by all submodules, etc.
*-module-[a-z] - application modules contains business logic, endpoints, shared entities. There modules are not deployable artifacts.
*-deployment - Deployable Quarkus application which can use other modules as dependencies, can contain other business logic and / or endpoints, entities, whatever.
aggregator
There are two remarkable things in the
<pluginManagement>section.maven-jar-pluginconfigured to create another artifact which contains test classes (more precisely all classes and resources under test folder). This configuration allows us to share even integration tests between other modules.quarkus-maven-pluginconfigured a little differently than as usual. Thebuildgoal moved under another<execution>section and got an<id>tag. From now, thebuild(which creates a deployable artifact) goal can be eliminated when it is needed,non-deployable application modules
A non-deployable Quarkus module can be referenced as a dependency, it can be started during the test phase but it cannot be started like a standalone Quarkus application. By binding the
build-deployable-appexecution to thenonelifecycle phase,quarkus:buildgoal will be disabled.Don't forget to make these modules discoverable to the main (deployable) module's CDI bean discovery mechanism by configuring
jandex-maven-pluginor by adding abeans.xmlto every non-deployable submodules.deploymentdeployable moduleIn the Quarkus ecosystem the deployment module means totally different. Every Quarkus extension has a
deploymentsubmodule that handles build time processing and so on.In this case a deployment module has to be build as a deployable Quarkus application using other submodules and probably some own code (e.g. other Rest endpoint)
Here, the
buildgoal ofquarkus-maven-pluginenabled and bound topackagelifecycle phase by default.Write, share and run tests
Let's say every module has own tests. Every test class that annotated with
@QuarkusTestshould run during the submodule'stestphase, but the@QuarkusIntegrationTests should be shared and run duringintegration-testphase of deployment module.Share tests between modules
In the aggregator module
maven-jar-pluginhas already configured to create test jar artifact. These artifacts are available like:Enable / disable integration tests
In the aggreagator module the integration tests disabled by default by using
<skipITs>true</skipITs>property. Well, disabling the skipping of integration test will enable them, won't it? In the deployment moduleskipITsproperty has to be set tofalseRun integration tests from dependent modules
In order to run integration tests from external artifacts the
maven-failsafe-pluginhas to be configured properly. ThedependenciesToScanparameter allows to specify and execute integration tests from dependencies.Important! All those included dependencies must already be defined in
<dependencies>For further options see the official documentation.