Overriding Helidon Third Party Dependencies

Helidon uses a number of third party dependencies. The versions of these dependencies are carefully managed by Helidon's dependencies/pom.xml. This ensures a consistent, converged set of dependencies.

In general you want to use the versions of these dependencies that are specified by Helidon. These have been tested together and are known to work with each other and with Helidon. Any time you override a dependency version you are incurring some degree of risk.

But there are cases where you might need to break this guidance. For example if a third party has a new CVE you might need to upgrade it immediately and not wait for a new version of Helidon.

What dependencies are safe to override?

In Helidon some dependencies are riskier to override than others. Here are some guidelines:

1. Upgrade, don't downgrade.
2. Upgrade only to a fully compatible version of the dependency. This means sticking with micro/patch releases -- no major, and possibly no minor.
3. Upgrade to a version that has been adopted by Helidon already (in a later release for example).
4. Netty and Jackson are often requested upgrades due to CVEs and these are generally safe upgrades providing you stick to micro/patch releases.
5. Simple client libraries (like Prometheus Simple Client) are also reasonably safe upgrades.
6. APIs that Helidon implements are dangerous to upgrade. So upgrading Jakarta EE APIs, MicroProfile APIs, OpenTracing APIs, etc is discouraged.
7. Jersey, due to the size of its dependency graph and tight integration with Helidon can be a risky upgrade even for micro releases.

How to override a Helidon dependency

There are two scenarios:

• You use a Helidon application pom as a parent pom (io.helidon.applications:helidon-mp or helidon-se)
• You do not use a Helidon application pom as a parent pom

You use a Helidon application pom

In this case you simply redefine the property that Helidon uses to control the version of the dependency. You can see the set of properties near the top of dependencies/pom.xml (you should replace master with the version of Helidon you are using).

For example, to force the version of Jackson to 2.12.2 you add this to your project's pom.xml:

    <properties>
        <version.lib.jackson>2.12.2</version.lib.jackson>
    </properties>

You do not use a Helidon application pom

If you have a standalone project and import io.helidon:helidon-dependencies directly into your dependencyManagement then redefining the property as described above is not sufficient. Instead you need to manage the dependency version explicitly in your pom. For example

    <properties>
        <my.version.lib.snakeyaml>1.28</my.version.lib.snakeyaml>
    </properties>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>io.helidon</groupId>
                <artifactId>helidon-dependencies</artifactId>
                <version>${helidon.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>org.yaml</groupId>
                <artifactId>snakeyaml</artifactId>
                <version>${my.version.lib.snakeyaml}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

Keep in mind that some third party dependencies consist of multiple artifacts -- in this case you'll need to manage the version of each artifact to ensure you don't mix multiple versions. Make sure you inspect your dependency tree (mvn dependency:tree) closely to check for version divergence.