Instead of using the official vendordeps solution for dependencies, my team has opted to instead use the standard functionality of Gradle. We add the repositories and dependencies to our build.gradle instead of having a json in vendordeps. At the beginning of the build season when doing some early testing, we found out that the Phoenix library (for CTRE products, such as the TalonSRX) was no longer installed separately, but instead baked-into your program. So we deployed once with Vendordeps to made sure that it worked, and then added the JNI dependencies to our build.gradle and all was well. But then, we re-imaged the RoboRIO and the libraries weren’t getting deployed. It turns out it worked because of that initial time we deployed with Vendordeps. Does anybody know the mechanism that is used to deploy the libraries? Or any modifications we can make to our build.gradle to make it work? Here’s our build.gradle
I think it’s possible to replicate the functionality of vendordeps with standard dependencies, but I highly recommend you don’t do that.
Vendordeps are a great feature and although aren’t standard, I think the WPI devs have their reasons for that.
One reason I can guess is that your dependencies don’t include the native dependencies (the cpp binaries that are called from Java).
I believe vendordeps are installed just like regular dependencies, it’s just that they don’t just have one dependency, they have multiple things that need to be installed.
I don’t have a deep understanding of vendordeps, but I hope that helped.
As said above, we very much recommend vendor deps, and there are some very critical reasons to use them.
The answer is different for c++ and Java. For c++, there is no standard dependency management, so it’s basically the only option.
For Java, it solves jni problems. It makes it easy for vendors to update their libraries and all the dependencies. Because of how the jni deps work, they cannot support transitive dependencies, so if a vendor wants to add another jni requirement in an update, they can without requiring manual intervention by the user.
For actual Java code, you could just use standard library mechanisms, but vendor deps are the only way to get the jni libraries working. It’s some internal data structures that handle it, and exposing it would require basically just copy pasting the jni portions of the vendor file into build.gradle. That would be very temperamental and hard to update, which is why we don’t support it, and why we have the external file.