v3.19 on maven-central no longer declares external dependencies

[cheppsn]

After upgrading our docusign-esign-java dependency to 3.19, code didn't build anymore.

It seems that the external dependencies are no longer packaged or properly declared in that library, so that they are no longer pulled in by local builds.

This is also reflected by the fact that 3.19 on maven central no longer has "compile dependencies" (https://mvnrepository.com/artifact/com.docusign/docusign-esign-java/3.19.0) compared to 3.18 which still does (https://mvnrepository.com/artifact/com.docusign/docusign-esign-java/3.18.0).

It's nice that the vulnerability is gone too, but I fear it's rather because there are no transitive dependencies declared anymore and not because the problem has been fixed.

It looks like upgrade to 3.19 was major (the commit touched > 500 files), but the release notes on github don't say much.

[mmallis87]

@cheppsn explicit dependencies created lot of version conflicts for a lot of users. The decision was to use uber jar. Here is how you can get 3.19.0 with Maven (similar syntax exits for Gradle and others):

<dependency>
  <groupId>com.docusign</groupId>
  <artifactId>docusign-esign-java</artifactId>
  <version>3.19.0</version>
  <classifier>shaded</classifier>
</dependency>

[cheppsn]

@mmallis87 Thanks for the information, we'll switch over to that one then 👍

If I may recommend updating the release notes on github? (this is our primary source of information when updating libraries) Also it seems that probably #211 and #197 can be closed or updated accordingly.

[davidsubskribe]

@cheppsn @mmallis87 Please see comment here regarding this issue

[abhishekmohite]

@mmallis87, do you happen to know Ivy dependency config equivalent of Maven that you mentioned here https://github.com/docusign/docusign-esign-java-client/issues/234#issuecomment-1139825191?

Thanks!

[cheppsn]

I have two problems with the current approach:

• using the unshaded version (without dependencies) is leaving the user/client unaware of the dependencies that need to be provided (one has to look them up in the POM and update them by hand, whenever the docusign client is upgraded) -> this is what we are doing since the last upgrade
• using the shaded version in a server environment is worse, as the packaged classes may conflict with the rest of the application dependencies. because the dependencies are no longer explicit, a dependency management like spring boot can not lift/adjust the versions and the conflicting classes stay on the classpath (not an option)

It would be very helpful, if the produced artifact would at least declare the dependencies that need to be provided (i.e. as "soft dependencies"), so that they are explicitly declared and can either be excluded by the build config (if conflicting) or managed by something like the Spring Boot dependency management plugin (gradle or maven).

I assume that defining a parent POM with the provided dependencies would already suffice.

[madisparn]

I think the shaded dependencies should also be relocated, to reduce duplicate classes at runtime when the using project has same dependency declared.

[OlivierJaquemet]

Not declaring external dependencies can pose real challenges for users of the DocuSign API as it prevents them from doing proper dependency management tasks such as :

• Verifying dependencies compatibility against the versions of libraries they currently utilize.
• Assessing dependencies using security tools like Snyk, OWASP dependency-check (or even github).
• Efficiently retrieving all dependencies during the build process

And using a "shaded/fat" jar is not recommended for all the same reasons.

@eleanorharris @osidenate @TonyMannDS would it be possible for you to address this issue in the upcoming fix version?