-
Notifications
You must be signed in to change notification settings - Fork 564
Discussion: How to Structure Integrations
We have several integrations of Helidon with other technologies, for both Helidon SE and Helidon MP. I have built another one—for Micrometer support—and before I recreate the PR for it Tomas suggested in a Slack DM that we have a broader discussion for how to handle these integrations.
So far, we have used various approaches for how to structure the Helidon SE and Helidon MP modules for these integrations, as Tomas summarized:
Summary | Location for SE module | Location for MP module | Adv | Disadv |
---|---|---|---|---|
First-class citizen |
|
|
Follows our familiar approach of putting SE modules as children of the top-level and modules for Helidon MP under |
Not really appropriate if |
Integration-level citizen, two modules |
|
|
Follows our familiar approach which separates the Helidon SE and Helidon MP code. |
Seems slightly odd to repeat the technology name in the SE module location. |
|
|
|||
Integration-level citizen, one module |
|
Reduces the number of modules in the system. |
Looks slightly odd to have annotations in a module that is usable from Helidon SE. CDI behavior of |
The "Integration-level citizen, one module" approach declares a dependency on CDI using
<scope>provided</scope>
<optional>true</optional>