Closed christophd closed 1 year ago
Thanks for reporting. Not sure if this is a bug or some kind of design behavior. @lburgazzoli wdyt? would it be harmful if we let also these components to slip into the catalog?
I don't recall any specific reason to exclude them, I think it at the time the catalog was introduced, the miscellaneous/other where probably things like camel-main and so on.
What component are actually labelled as miscellaneous/other ?
The one that made me realize this issue is camel-jta
and camel-cloudevents
which is also listed in the Camel Quarkus extensions but has not been part of the catalog
@lburgazzoli this is the list of components labelled as miscellaneous https://camel.apache.org/components/3.20.x/others/index.html
camel-cloudevents
cannot be really defined as a component as it does not provide any component or dataformat or language and it is mainly a support dependency for other components so there won't be any schema associated with that. The camel-jta
seems to fall in the same category so I guess we should use some additional info to decide to include them or not
In case the Camel dependency is not listed in the catalog Camel K will raise warnings and the runtime is not using the respective Quarkus extension camel-quarkus-jta
if it is not listed in the catalog.
The way it is implemented right now the integration will even fail with errors in case the Camel dependency is not listed in the catalog. We are about to change that to raise warnings instead of failing. These are the miscellaneous components that do have a Camel Quarkus extension:
attachments
aws-xray
caffeine-lrucache
cloudevents
console
core-cloud
debug
dsl-modeline
groovy-dsl
headersmap
jasypt
java-joor-dsl
jfr
js-dsl
jsh-dsl
jta
knative-consumer
knative-producer
kotlin
kotlin-dsl
leveldb
lra
management
microprofile-fault-tolerance
microprofile-health
openapi-java
opentelemetry
opentracing
reactive-executor-vertx
redis
shiro
smallrye-reactive-messaging
threadpoolfactory-vertx
xml-io-dsl
xml-jaxb
xml-jaxp
yaml-dsl
Ah ok, that's not for scheme -> dependency resolution but for generic dependency resolution so yes, in that case we should add all the dependencies.
I understand this is now completed.
Camel components categorized as miscellaneous/other are currently ignored when building the Camel catalog. We should include those components in order to also resolve these artifacts via the catalog.