This seems less linking and more dependency resolution.
What was wrong with
> ./gradlew dependencies
and then sorting out your duplicate dependencies with improper version issues.
I have spent a lot of time down this road myself and most of it was not fully understanding the framework dependencies, munging of stackoverflow solutions, or apache-commons hell...sometimes a little bit of it all.
Not trying to crap on your hardwork but interested in your motivations if its something bigger which I am not seeing.
Long term I don't think you can properly suggest the appropriate dependency, this is why most build tools provide default selection and let you override with exclude patterns.
Additionally there is a linting tool that will parse through duplicates and offer to clean up your gradle files if that is interesting to you alongside your work.
What was wrong with
> ./gradlew dependencies
and then sorting out your duplicate dependencies with improper version issues.
I have spent a lot of time down this road myself and most of it was not fully understanding the framework dependencies, munging of stackoverflow solutions, or apache-commons hell...sometimes a little bit of it all.
Not trying to crap on your hardwork but interested in your motivations if its something bigger which I am not seeing.
Long term I don't think you can properly suggest the appropriate dependency, this is why most build tools provide default selection and let you override with exclude patterns.
Additionally there is a linting tool that will parse through duplicates and offer to clean up your gradle files if that is interesting to you alongside your work.