Register extensions from quarkus-renarde

[github-actions]

This PR registers newly discovered extensions from quarkus-renarde.

New extensions

• quarkus-renarde-backoffice (io.quarkiverse.renarde) (cc @quarkiverse/quarkiverse-renarde)
• quarkus-renarde-jpa (io.quarkiverse.renarde) (cc @quarkiverse/quarkiverse-renarde)
• quarkus-renarde-transporter (io.quarkiverse.renarde) (cc @quarkiverse/quarkiverse-renarde)

---

Created automatically by auto-register-extensions

[holly-cummins]

cc @FroMage

[holly-cummins]

What this does is make the extension available on extensions.quarkus.io and code.quarkus.io. More details are here: https://hub.quarkiverse.io/checklistfornewprojects/#make-your-extension-available-in-the-tooling

[FroMage]

🤔 I wonder what to do with those. They're optional modules of Renarde, but they're not the only optional modules: some of the others are not extensions. These have to be, but from the user's PoV they're not different. So why list those, but not the others?

I am unsure what the policy around optional extension modules is and what to do here…

[holly-cummins]

Yeah, we've had a few similar tricky cases. I guess one question is 'would anyone ever want to do quarkus ext add quarkus-renarde-jpa (or whatever)?

[FroMage]

Yes, they would, equally whether it's a module or extension. The only ones that we don't want people to explicitly add are modules/extensions that are meant to be used as dependencies by front-facing modules/extensions.

[holly-cummins]

Ok, sounds like it should go into the registry?

[FroMage]

We can only add extensions in the registry, right?

If yes, then I think we have a problem, because I don't think it makes sense to list an (toplevel) extension's optional extensions, but not its non-extension optional modules. From the PoV of users these should be equal: they provide optional functionality and nobody cares whether it's an extension or not. If we add only optional extensions, then users might think that that's all there is, but it's not, and they will need to look at the docs to find out what's missing from completion.

[holly-cummins]

Oof, yes, I don't think we really considered non-extension modules for extensions. We have a few of those in main quarkus, like JUnit, and they frustrate me because the process for managing those dependencies is different than for everything else. I've been tempted to make it an extension just for consistency but that's kind of the tail wagging the dog.

[FroMage]

Renarde has these modules:

• pdf
• barcode
• test
• backoffice (extension)
• transporter (extension)
• oidc
• jpa
• security

I don't think users should treat any of those differently based on them being extensions or simple modules.

BTW, I think jpa is not an extension, unlike your PR description. It does have a deployment module, but only for backoffice and transporter which depend on it. It could be an extension, but it has zero build-time actions (no build steps), just some data classes shared by the extensions which depend on it. It does not have any extension metadata, I think. What makes you think it's an extension? 🤔 I mean, how did you detect this?