Proposal: include community/Quarkiverse dev services on https://quarkus.io/guides/dev-services

[holly-cummins]

At the moment, https://quarkus.io/guides/dev-services says "This page lists all the Dev Services that Quarkus supports." However it only lists a hand-curated set of dev services, which are mostly ones from the core Quarkus repo – with an exception for neo4j. Since the page mostly functions as a catalog, it would be nice to make it a more inclusive list, perhaps with a 'Community' or 'Quarkiverse' section that lists other dev services we know about.

Hand-curating that list may not be very scalable or sustainable, so we might want an automation to maintain the page. (Either just to render a list, based on what we know about from the registry, or to maintain content similar to what's there now, with a description about what the dev service does and perhaps also configuration information.

What do you think, @maxandersen @gastaldi @gsmet?

[gastaldi]

Sounds good, for community/Quarkiverse extensions, to avoid changing this page frequently, I believe it would be better if we had a link to the respective docs.quarkiverse.io page instead.

Or maybe we could have a page in the docs.quarkiverse.io grouping all the community devservices (same with configs, build items, etc), which then would be automatically generated every x hours.

[maxandersen]

Let's make sure we use proper names here - All of them are community developed.

The only real difference is whether they are in the io.quarkus platform.

I do think we should have a page where possible to see the list of devservices for better discovery.

Thus in short/mid time I'm +1 on adding links to other devservices. Maybe have one list of "included in Qurkus platform" and a "other" list.

In general though this is just another specific example of the mismatch between docs for what is maintained/supported in a platform vs what is available in overall ecosystem. Other examples are our all config page, and doc index having mix of extensions in and outside of platform and missing large parts (ie. Camel)

Should we make a more dedicated Qurkus.i/devservices page with this info or maybe somehow on extensions.quarkus.io based on registry metadata?

[holly-cummins]

Let's make sure we use proper names here - All of them are community developed.

Good point. I wrote 'Quarkiverse' initially but then decided it maybe wasn't the right word, it's a bit overloaded, but you're right about 'Community'. I didn't think of 'Platform' as headings since at the moment the guide page is a mix of platform and non-platform extensions. The main criteria at the moment is 'in the Quarkus repo', but even that's not perfect.

The following are non-platform:

• Neo4J
• RabbitMQ (included in the main quarkus repo)
• Redis (included in the main quarkus repo)

The following are platform (so a majority, but not all):

• AMQP
• Apicurio
• Databases
• Kafka
• Keycloak
• Vault
• Elasticsearch
• Infinispan

'Included in the Quarkus repo' definitely doesn't seem like the right criteria, so agreed on 'Included in the Quarkus platform' and 'other' as the headings. We'll need to do a preliminary pass to sort out the current non-platform extensions (like Redis) on the page, and then investigate the lowest-maintenance way of pulling in the non-platform extensions.

Should we make a more dedicated Qurkus.i/devservices page with this info or maybe somehow on extensions.quarkus.io based on registry metadata?

We could, but I think we'd also want to significantly modify the existing page - it says it's a catalog of all Quarkus dev services, and it's not. There's no mention of the platform on the page. The closest it comes is 'support' but that's also a very overloaded term. :)

In general though this is just another specific example of the mismatch between docs for what is maintained/supported in a platform vs what is available in overall ecosystem. Other examples are our all config page, and doc index having mix of extensions in and outside of platform and missing large parts (ie. Camel)

A very good point. If we're lucky, what we do here can be generalised.

[holly-cummins]

See https://quarkus.io/version/main/guides/dev-services for new content.

[holly-cummins]

I've also raised quarkusio/extensions#983, which (once all the supporting infrastructure is in place) would allow us to have urls like https://quarkus.io/extensions?provides-dev-service=true to see a dynamically generated list all extensions which provide a dev service.

The same backing infrastructure could be used to generate content for https://quarkus.io/guides/dev-services if we want.

[aloubyansky]

Correct me if I'm wrong here, but when you refer to "platform" here you actually cover just the core quarkus, not the rest of the actual platform?

[maxandersen]

@aloubyansky not sure which comment you refer to specifically about "platform" but my reference to platform is the actual io.quarkus.platform:* so not just core quarkus.

[aloubyansky]

Right, that's how it should be. I have an impression it isn't actually fully covered currently.