How to separate unlisted extensions from the listed ones?

[agoncal]

Today under the extensions directory, we have some listed extensions, such as app-configuration or storage-blob as well as unlisted ones http-client-vertx or core. So, looking at the repo and the structure of the directory, it's not clear of which are extensions that can be used by external projects or not.

Wondering if we could have an extensions directory and an internal directory ? Or maybe just prefix the listed extensions with azure, this way we will have azure-app-configuration or azure-storage-blob

@ppalaga any thoughts on that ?

[agoncal]

BTW @ppalaga @radcortez @maxandersen @zbendhiba any suggestion on how to refactor the repo so listed extensions are easier to find?

[radcortez]

We don't have a strict structure to follow. In Quarkus, we have everything in extensions and core / common stuff in a separate core root folder. So maybe we could do something like:

• bom
• core
  • common (moved from extensions - old core)
  • http-client-vertx (moved from extensions)
  • jackson-dataformat-xml (moved from extensions)
• docs
• extensions (public extensions for azure)
  • azure-app-configuration (rename from app-configuration)
  • azure-storage-blob (rename from storage-blob)
• integration-tests

[maxandersen]

I wouldnt tie physical repo structure to what is made availble by tooling or not. That most likely evolve.

[agoncal]

@maxandersen no but I like to have extensions under the extension directory. Today there are also internal content under extensions, which is not very clear (even to me)

[zbendhiba]

In Camel-Quarkus, we do have also some internal extensions, and we have a dedicated directory extensions-support

IMHO, using internal or core are better names.

[ppalaga]

Sorry for coming so late. Yes, I agree having the ancillary extensions in a separate folder might be practical for several reasons:

• Contributors can see what is intended for public use
• Various checks can be bound to those directories: quarkus metadata, existence of a documentation page, existence of a test, etc.

Or maybe just prefix the listed extensions with azure, this way we will have azure-app-configuration or azure-storage-blob

quarkus-azure- prefix is better IMO. The azure- prefix might awake the impression that they are some sort of official Azure artifacts, which they are not.

[agoncal]

Good point @ppalaga. I created https://github.com/quarkiverse/quarkus-azure-services/issues/64