Dependency management

A specific Camel Quarkus release is supposed to work only with a specific Quarkus release.

Quarkus tooling for starting a new project

The easiest and most straightforward way to get the dependency versions right in a new project is to use one of the Quarkus tools:

All of these allow you to select extensions and scaffold a new Maven or Gradle project.

The universe of available extensions spans over Quarkus Core, Camel Quarkus and several other third party participating projects, such as Hazelcast, Cassandra, Kogito, OptaPlanner, etc.

The generated pom.xml will look similar to the following:

<project>
  ...
  <properties>
    <quarkus.platform.version>3.17.4</quarkus.platform.version>
    ...
  </properties>
  <dependencyManagement>
    <dependencies>
      <!-- The BOMs managing the dependency versions -->
      <dependency>
        <groupId>io.quarkus.platform</groupId>
        <artifactId>quarkus-bom</artifactId>
        <version>${quarkus.platform.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>io.quarkus.platform</groupId>
        <artifactId>quarkus-camel-bom</artifactId>
        <version>${quarkus.platform.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>

  <dependencies>
    <!-- The extensions you chose in the project generator tool -->
    <dependency>
      <groupId>org.apache.camel.quarkus</groupId>
      <artifactId>camel-quarkus-sql</artifactId>
      <!-- No explicit version required here and below -->
    </dependency>
    ...
  </dependencies>
  ...
</project>

BOM stands for "Bill of Materials" - it is a pom.xml whose main purpose is to manage the versions of artifacts so that end users importing the BOM in their projects do not need to care which particular versions of the artifacts are supposed to work together. In other words, having a BOM imported in the <depependencyManagement> section of your pom.xml allows you to avoid specifying versions for the dependencies managed by the given BOM.

Which particular BOMs end up in the pom.xml file depends on extensions you have selected in the generator tool. The generator tools take care to select a minimal consistent set.

If you choose to add an extension at a later point that is not managed by any of the BOMs in your pom.xml file, you do not need to search for the appropriate BOM manually. With Quarkus CLI you can select the extension, and the tool adds the appropriate BOM as needed. Quarkus CLI also comes in handy when upgrading the BOM versions.

The io.quarkus.platform BOMs are aligned with each other. That means that if an artifact is managed more than one BOM, it is always managed in the same version. This has the advantage that application developers do not need to care for the compatibility of the individual artifacts that may come from various independent projects. Note that not all combinations of artifacts managed by the various BOMs are tested.

Combining with other BOMs

When combining quarkus-camel-bom with any other BOM, think carefully in which order you import them, because the order of imports defines the precedence.

I.e. if my-foo-bom is imported before quarkus-camel-bom then the versions defined in my-foo-bom will take the precedence. This might or might not be what you want, depending on whether there are any overlaps between my-foo-bom and quarkus-camel-bom and depending on whether those versions with higher precedence work with the rest of the artifacts managed in quarkus-camel-bom.

Upgrading to new Camel Quarkus releases

Assuming you are importing quarkus-bom and quarkus-camel-bom in your project, upgrading to new releases should be a simple case of incrementing the quarkus.platform.version property.

Sometimes it happens that the latest Camel Quarkus release is not yet availble via the quarkus-camel-bom. To work around this, you can replace the io.quarkus.platform:quarkus-camel-bom import with org.apache.camel.quarkus:camel-quarkus-bom.

Note that if you do this, some dependencies in camel-quarkus-bom may not be perfectly aligned with other Quarkus universe members as they would be in quarkus-camel-bom.

<project>
  ...
  <properties>
    <quarkus.platform.version>3.17.4</quarkus.platform.version>
    <camel-quarkus.version>3.18.0</camel-quarkus.version>
    ...
  </properties>
  <dependencyManagement>
    <dependencies>
      <!-- The BOMs managing the dependency versions -->
      <dependency>
        <groupId>io.quarkus.platform</groupId>
        <artifactId>quarkus-bom</artifactId>
        <version>${quarkus.platform.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.apache.camel.quarkus</groupId>
        <artifactId>camel-quarkus-bom</artifactId>
        <version>${camel-quarkus.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>
Ensure that the major.minor version parts of quarkus.platform.version & camel-quarkus.version match. Mixing different release streams will likely result in build or runtime errors.

When upgrading from one major release to another (E.g from 2.x to 3.x). Quarkus provides an updater tool that can apply the necessary modifications to your project and make it compatible with the new major release.

In addition, Camel & Camel Quarkus publish migration guides that document potential breaking changes.

What’s next?

We recommend to continue with Defining routes.

Back to top