Transitive dependencies are gone in version 4.1.0

[ksiczek]

Hi there,

it seems that 4.1.0 does not declare some (or most) of the dependencies making us declare them on our own explicitly. Would you mind explaining if not publishing the information on dependencies was intentional and if there was any reasoning behind that? We know, we could use the shaded version of the client dependency but we would not like the idea.

Regards, a new client ;)

[JohnHuynh]

I also came to the point where we could not execute code creating an ApiClient() for example without specifying the shaded classifier.

Explanation much needed :)

[ksiczek]

Actually, the dependencies are gone in 3.23.0. The list of dependencies in the README might be a little bit misleading since it does not map the version of the library to the dependency version. However, I wonder why the required dependencies are not transitive in the first place 🤔

[cbollmeyer]

Actually, the dependencies are gone since 3.19 because they obviously created 'a lot of version conflicts for a lot of users'. (https://github.com/docusign/docusign-esign-java-client/issues/234). Instead, the 'shaded' artifact came into place which is in fact a Fat Jar - without relocation though, it seems, so it still leads to version conflicts at least in server environments and many dependencies were outdated, some had known security issues and so on. Let's not go further into this. For us, the Fat Jar is no option.

Luckily, the code is open source, so you can get the dependency list from the project's pom.xml (at the bottom). That's what we use and simply redeclared those dependencies we don't already use in our own project, which enables us to override versions in case of conflicts or required security upgrades. There are Gradle build files as well, but these seem to be outdated and TBH JUnit 4 is too.

Note that since version 4, the client uses Jakarta instead of JEE 8 libraries now, so that may not be a simple drop-in replacement. In case of Spring Boot, it also requires a switch to Version 3+ and JDK 17 which is no minor task. Some kind of announcement would have been nice, but well.

[ksiczek]

Thank you @cbollmeyer for taking care to answer and pointing the #234. I can imagine that maintaining a library might be challenging but it seems to me that a dependency-less version suits no one, doesn't it? In case there is no conflict, clients should be able to use as-is or re-declare dependencies enforcing a particular version - dependency management tools allow us to declare whatever we please. However, if there is a conflict hiding dependencies does not help at all. Regarding vulnerabilities and bumping dependencies up it is up to the maintainer to check if everything works fine and is compatible.

BTW, regarding versions we were probably both right - I checked 3.22.0 and the dependencies are declared so I stopped verifying. However, wiping them out before publishing is probably a custom step that sb forgot to do.

Actually, it is a pity that for almost a year (since #234) the topic got almost no attention besides some trivial explanation and I think we would better proceed with a custom HTTP client on a stack we maintain anyway.

[cbollmeyer]

IIRC the developers said somewhere the reappearance of the dependencies in 3.22 was in fact a mistake. Indeed it's a little odd, but believe me, you had to redeclare most of the stuff including Jackson 2.12 or Jersey 2 anyway, as those were outdated and had known security bugs. Not to mention the json.org dependency the attic-ized apache oltu lib uses (it still does) which was from 2014. Idk, it is as it is. As you mention it, we too went migrating to a custom HTTP client for some of our projects, reusing only the model component for JSON serialization, but then, you have to deal with the API changes on your own. That pull request for the Refresh Token support (which the client still lacks) is pending review since...2021?

[ksiczek]

So far we seem lucky to use just authentication flow and one envelope call and we could give custom implementation a try. Moreover, we do work in a BE-to-BE manner and we did not suffer from the lack of refresh tokens yet. The talk was really insightful and helpful 😌 but I'm going to close the issue because it seems unlikely I get something more.

Take care.

[ksiczek]

Closing as it is way too difficult to get some answers and we've finally decided to switch to a custom implementation.