Here some documentation related to how Camel K manages dependencies: https://camel.apache.org/camel-k/1.7.x/configuration/dependencies.html
The most important managed component dependencies are the ones discovered in the route definition. Those are always picked and included in the integration. Then we have certain dependencies managed by traits (ie, metrics, logging, knative, ...). Finally there are the dependencies provided by user, either via kamel run -d or modeline. The latter are included in the integration when the command is executed by the CLI, otherwise you need to specify manually in the Integration spec. Regards, Pasquale. On Tue, Dec 21, 2021 at 12:14 PM Roberto Camelk < [email protected]> wrote: > So, If I try to use some dependency like camel:rest it will not be > resolved even if I put it on a modeline (and submit the yaml to the > k8s API) ? > > On Tue, Dec 21, 2021 at 6:24 AM Pasquale Congiusti > <[email protected]> wrote: > > > > Hello Roberto, > > the cron dependency is likely autodiscovered from your component route > > definition (ie, cron:xyz), whilst the microprofile is instead defined by > > the prometheus trait, so, although you don't define it explicitly, then, > > the dependency is added during the application build. > > > > Regards, > > Pasquale. > > > > On Mon, Dec 20, 2021 at 5:39 PM Roberto Camelk < > [email protected]> > > wrote: > > > > > I'm launching camel-k integrations via kubernetes API. > > > > > > I just create an "Integration" resource definition in JSON and submit > it. > > > > > > Recently I was trying to create integrations with dependencies like > > > "camel:cron" and "camel:microprofile-metrics" but WITHOUT defining > > > them in the "dependencies" field. I leted this dependencies inside the > > > source code via "modeline", and for my amazement camel-k operator has > > > built the kit correctly. > > > > > > But the case is that the "Integration" resource (obtained via kubectl > > > get intergration <my-integraton> -o yaml) doesn't describe the > > > dependencies. > > > > > > Can I assume this is the expected behavior? That the operator will > > > "parse" the source and use the correct dependencies even if the source > > > Integration resource hasn't contracted them? > > > >
