Description

uses is just a working proposal. I am open to any better name.

1. Camel Quarkus wraps some specific version of Camel and it would be great if we could make that version visible to end users.
2. Camel Quarkus extensions may wrap some further library, such as HTTP or Hazelcast client and it would also be great to make those visible to users.
3. The cases 1. and 2. could be seen as a bit different: while Camel version holds for all extensions provided by Camel Quarkus (hence it is Platform participant level), the Hazelcast and HTTP client versions are extension specific. I am not sure we really need to have two levels of the metadata, I just wanted to mention this.
4. The cases 1. and 2. show that for a single extension, there might be more than one uses key-version pairs.
5. While it is easy to generate this metadata on the participant side, the version of the underlying uses dependency may get changed in the platform. So the value of the metadata should perhaps not be the actual version, but rather a groupId:artifactId for which the real version should be querried by Platform BOM generator from the participant BOM.
6. It would be great if the uses version information could also be visible on the Quarkus Platform compatibility matrix page I asked for when we discussed the new Platform BOM versioning scheme.

Implementation ideas

An example of quarkus-extension.yaml delivered by an extension:

---
name: "Camel AMQP"
...
metadata:
  ...
  uses:
    'Camel': 'org.apache.camel:camel-core'
    'ActiveMQ Client': 'org.apache.qpid:qpid-jms-client'

An example how the new metadata could be presented on code.quarkus.io: