You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by "lburgazzoli (via GitHub)" <gi...@apache.org> on 2023/05/24 07:48:33 UTC

[GitHub] [camel-k] lburgazzoli commented on pull request #4402: fix(#4361): Avoid errors when components not available in Camel catalog

lburgazzoli commented on PR #4402:
URL: https://github.com/apache/camel-k/pull/4402#issuecomment-1560618322

   > thanks @tadayosi for your comments.
   > 
   > > all valid dependencies for camel-k should be listed in the catalog
   > 
   > +1 but recent history has shown that the catalog may be incomplete (see [apache/camel-k-runtime#1029](https://github.com/apache/camel-k-runtime/issues/1029) which fixed that)
   > 
   > > Doesn't trying to use camel-resilience4j directly mean running a library not yet ready for Quarkus
   > 
   > I think the raw Camel component is not optimized for Quarkus but still is able to run isn't it?
   > 
   > Of course using the Camel Quarkus extensions should be the first choice and the catalog makes sure to use those extensions once they are listed. But we should not fail when the user explicitly uses a non-listed Camel dependency. This would then prevent any customized Camel components and other things that are not listed. In the past I have also been requesting the error based on the catalog checks but today I think this is too restrictive.
   
   I think we should made a distinction between:
   1. not optimized for the runtime or not known by the runtime 
   2. not supported by the runtime. 
   
   About case 1, we should allow the user to add such dependency as it could be a component/extension non part of the camel distribution but still a valid component/extensions. However in such case I think the user should define the component using a maven coordinate and the component should not use the ´camel.apache.org` as artifact group  which should bypass the catalog check (at least this is what I recall). 
   About case 2, I think the catalog can also include a list of banned dependencies so if we know ahead of time that a specific dependency can cause harm to the runtime, then we can either fail or ad a warning to the integration CR.
   
   Does this make any sense ?
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org