0

Our customer want us to provide them a lib from only the data layer of our multimodule spring boot project, that they can use in their whatever (probably spring) project. So they have to use our dependencies, but we do not really want to enforcing them to use specific versions that we use.

Our aim is to provide one publishable module in which:

  • our modules are shaded (very-neat-bigdata, very-neat-util, very-neat-other)
  • libs not shaded but added to published pom
  • don't want to exclude libs one by one

Our project looks like this:

very-neat-project
  very-neat-web
    -> spring-web 1.5.4
  very-neat-bigdata            <- this
    -> spring-context 1.5.4
    -> hbase
    -> very-neat-util
      -> guava 26
    -> very-neat-other
      -> common.util 1.5.6
    -> ...ton of other dependency...

So our approach would be to create a shaded lib that customer can include to their project like this:

customer-project
  customer-web
    -> spring-web 1.6.8
    -> spring-context 1.6.8
    -> very-neat-bigdata-shaded <- this
    -> guava 28
    -> hbase
    -> common.util 1.5.4
    -> ..ton of other dependency..

How to solve this using gradle? Or if is this a bad approach what would be the best practice for this problem?

Daniel Hári
  • 7,254
  • 5
  • 39
  • 54
  • *but we do not really want to enforcing them to use specific versions that we use* Huh!?!?! You're going to let a customer swap out versions of things that your code literally **depends** on? How do you plan on verifying that your code will work with `foo vX.X.X` when your code uses `foo v12.3.121` and you don't even know what `X.X.X` is? If you can isolate the functionality they want into a separate jar, that's different, but you still have **dependencies**. – Andrew Henle Apr 14 '23 at 18:56
  • Ok you are probably right, this approach is bad, then what is your advice to solve the issue? Shade and relocate all dependency except our api in a fat jar? – Daniel Hári Apr 14 '23 at 20:36

0 Answers0