Dependencies and Component Resolution
Camel K tries to resolve automatically a wide range of dependencies that are required to run your integration code.
For example, take the following integration:
Since the integration has a endpoint starting with the "imap:" prefix, Camel K is able to automatically add the "camel-mail" component to the list of required dependencies. The
seda: endpoint belongs to
camel-core that is automatically added to all integrations, so Camel K will not add additional dependencies for it. This dependency resolution mechanism is transparent to the user, that will just see the integration running.
Automatic resolution is also a nice feature in dev mode, because you are allowed to add all components you need without exiting the dev loop.
|Camel K won’t be able to automatically the dependencies when your routes specify dynamic URIs.|
You can explicitly add dependency using the
-d flag of the
kamel run command. This is useful when you need to use dependencies that are not included in the Camel catalog or when the URI of your routes cannot be automatically discovered (see Dynamic URIs). For example:
kamel run -d mvn:com.google.guava:guava:26.0-jre -d camel-mina2 Integration.java
With that command you will add a dependency of Guava and the Camel Mina component. This feature can also be disabled if needed (although we discourage you from doing it) by disabling the dependencies trait (
-d flag of the
kamel run command is flexible and support multiple kind of dependencies.
Camel dependencies can be added directly using the
-d flag like this:
kamel run -d camel-mina2 Integration.java
In this case, the dependency will be added with the correct version.
External dependencies can be added using the
-d flag, the
mvn prefix, and the maven coordinates:
kamel run -d mvn:com.google.guava:guava:26.0-jre Integration.java
Note that if your dependencies belong to a private repository, this repository needs to be defined. See Configure maven.
If your dependency is not published in a
maven repository you will find very useful Jitpack as a way to provide any custom dependency to your runtime Integration environment. In certain occasion you will find useful to include not only your route definition, but also some helper class or any other class which has to be used while defining the Integration behavior. With Jitpack you will be able to compile on the fly a java project hosted in a remote repository and use the produced package as a dependency of your Integration.
The usage is the same as defined above for any maven dependency. It can be added using the
-d flag, but, this time, you need to define the prefix as expected for the project repository you are using (ie,
github). It has to be provided in the form
repository-kind:user/repo/version. As an example, you can provide the Apache Commons CSV dependency by executing:
kamel run -d github:apache/commons-csv/1.1 Integration.java
We support the most important public code repositories:
github:user/repo/version gitlab:user/repo/version bitbucket:user/repo/version gitee:user/repo/version azure:user/repo/version
version can be omitted when you are willing to use the
main branch. Otherwise it will represent the branch or tag used in the project repo. You can have a look at the Camel K Jitpack example to have a complete experience about how to include a dependency with this mechanism.
Unfortunately, Camel K won’t be able to always discover all your dependencies. When you are creating an URI dynamically, then you will also need to instruct Camel K on which is the expected component to load (via
-d parameter). An example is illustrated in the following code snippet:
... String myTopic = "purchases" from("kafka:" + myTopic + "? ... ") .to(...) ...
from URI is dynamically created from some variables that will be resolved at runtime. In cases like this, you will need to specify the component and the related dependency to be loaded in the