CODEWITHSUNDEEP
mavenmaven-3
divz
divz

Reputation: 7957

Maven dependency conflicts

I am trying to resolve dependency version conflicts while using the below dependencies.

The worst one I am facing is zucchini project supports the apache commons-io versions from 1.4 to latest one. It does not support versions below 1.4 and at the same time pagerduty-client supports commons-io versions below 1.4 version. So It is not possible to specify a common version of this dependency (dependency management) which supports in both zucchini and pager-duty client (both are third party libraries).

enter image description here

In this particular situation I couldn't find a possible way to resolve this issue. Any help will be appreciated.

        <dependency>
            <groupId>com.comcast.zucchini</groupId>
            <artifactId>zucchini</artifactId>
            <version>[2.2.5,)</version>

        </dependency>

        <dependency>
            <groupId>com.github.dikhan</groupId>
            <artifactId>pagerduty-client</artifactId>
            <version>3.0.2</version>
        </dependency>

Upvotes: 5

Views: 1211

Answers (2)

Paul Grime
Paul Grime

Reputation: 15104

Possibility 1

If the old and new commons-io package/class names are a close enough match, excluding the old dependency from pagerduty-client could possibly work.

https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html

    <dependency>
        <groupId>com.github.dikhan</groupId>
        <artifactId>pagerduty-client</artifactId>
        <version>3.0.2</version>
        <exclusions>
           <exclusion>
               <groupId>org.apache.commons</groupId>
               <artifactId>commons-io</artifactId>
           </exclusion>
       </exclusions> 
    </dependency>

This relies on the binary API of commons-io between versions 1.3.2 and 2.x being similar enough.

There does seem to be lots of overlap, looking at the code of each version:

Possibility 2

Split up your application so that the commons-io dependency is not shared and does not conflict.

It could be that the pagerduty-client and zucchini parts of your application do not need to be 'bundled' together, so split them up.

If they do need work together then you could still have two apps/processes and send messages between them.

Note

I cloned the pagerduty-client repo and changed the commons-io dependency from org.apache.commons:commons-io:1.3.2 to commons-io:commons-io:2.5 and the tests worked, so maybe you can suggest to the project owner that they upgrade commons-io.

And looking at the code it seems commons-io is hardly used (one place, HttpApiServiceImpl.java):

\pagerduty-client>findstr /s /c:"commons" *.java
src\main\java\com\github\dikhan\pagerduty\client\events\domain\AcknowledgeIncident.java:import org.apache.commons.lang3.StringUtils;
src\main\java\com\github\dikhan\pagerduty\client\events\domain\Incident.java:import org.apache.commons.lang3.StringUtils;
src\main\java\com\github\dikhan\pagerduty\client\events\domain\Incident.java:import org.apache.commons.lang3.builder.Builder;
src\main\java\com\github\dikhan\pagerduty\client\events\domain\Payload.java:import org.apache.commons.lang3.StringUtils;
src\main\java\com\github\dikhan\pagerduty\client\events\domain\ResolveIncident.java:import org.apache.commons.lang3.StringUtils;
src\main\java\com\github\dikhan\pagerduty\client\events\HttpApiServiceImpl.java:import org.apache.commons.io.IOUtils;
src\main\java\com\github\dikhan\pagerduty\client\events\PagerDutyEventsClient.java:import org.apache.commons.lang3.StringUtils;
src\main\java\com\github\dikhan\pagerduty\client\events\utils\FakePagerDutyEventsClient.java:import org.apache.commons.lang3.StringUtils;

Upvotes: 1

jwenting
jwenting

Reputation: 5663

As your commons-io is the problem you'll have to look further up the line. That means either upgrade pagerduty-client to a version that uses a newer version of commons-io that Cucumber likes, or downgrade zucchini to require a version of Cucumber that works with pagerduty-client as well.

This is a common problem with some jakarta commons packages, they at some point decided to massively change the public interface without changing the package name, causing conflicts like this for users.

You may be in luck, I once worked on a project where we had to rewrite thousands of lines of code just so we could link to a library we desperately needed that depended on a newer version of commons-io than the one we'd been using.

Upvotes: 1

Related Questions