CODEWITHSUNDEEP
javamavenapache-sparkhadoop
clorzs
clorzs

Reputation: 81

Maven different package name in newer dependency

The project I am working on produces a jar that I deploy on azure so Spark runs the job. It is using an internal dependency A which uses the dependency org.apache.commons:commons-configuration:1.10 yet when I deploy on azure it uses 2.1.1 version by default.

On azure we have the version 2.1.1 in which the package name(org.apache.commons.configuration2) differs from the 1.10 version ( org.apache.commons.configuration).

So having this line in the dependency A caused an error when using the 2.1.1 version:

Import org.apache.commons.configuration

It needs to be having "2" at the end, a thing I can t add as A is a dependency.

I tried excluding org.apache.commons:commons-configuration from A then using the maven shade plugin to rename the package but the jar file become double the actual size besides the shaded jar produced alone not inside the zip with the workflow and the sh file, a thing my team may not like.

Upvotes: 3

Views: 522

Answers (2)

Steve C
Steve C

Reputation: 19445

If you want to avoid using the maven-shade plugin than an alternative solution might be to:

  1. Exclude commons-configuration 1 in the library A dependency declaration;

  2. Work out which classes and methods from commons-configuration 1 that library A uses (easy enough if you have the source code, otherwise a modern IDE will disassemble it for you);

  3. Write your own versions of these classes and methods in your application that delegate to the commons-configuration2 implementation.

Note that commons-configuration2 is a part of the Apache Spark distribution and it cannot be ignored. It would need to be added to your project with <scope>provided</scope>.

If this is too hard then the maven-shade-plugin is your only viable solution.

Upvotes: 0

Karol Dowbecki
Karol Dowbecki

Reputation: 44952

Updating from commons-configuration 1 to 2 is a major change, the new version is not a drop-in replacement. As you have already pointed out the top level package changes and this will most likely brake library A. The correct solution will probably be to update library A to use commons-configuration 2.

You can still try to hack the Maven project setup to see if it works:

  1. Exclude commons-configuration 1 from library A dependency using <exclude> tag.
  2. Add commons-configuration 2 as a direct project dependency with provided scope in module B. The provided scope is needed to avoid packaging the dependency.

Upvotes: 1

Related Questions