Adding My Team's Library as a Vendor Library?



Before the official 2019 release of WPILib, we’ve exported our team’s Java library as a JAR file, put it in WPILib’s java libs folder and added its path as a project dependency.
Now, there’s this thing which I don’t quite understand. Does this should change the way we add our team’s library to our project or is it intended to make it easier for teams to add 3rd party sensor libraries to their projects, for example?

P.S: I’m still kinda new to the whole VS Code thing, adding external libraries in Eclipse was much easier imo :persevere:


Adding a jar dependency is very simple. Create a ‘libs’ folder in your project directory. Then, in your build.gradle, add this line to the dependencies block:

compile fileTree(dir: 'libs', include: ['*.jar'])

That will add any jar file in that folder as a dependency.


It’s sort of what we did, what I’m more interested about is this new vendor library feature that WPILib offers. Is it relevant to teams that want to add their own personal frc Java libraries?


The vendor library feature allows management of complex features such as jni. If you library is java only, then it’s easier to just use gradle to manage the dependencies. If your library is on github and buildable by, you can use it to host your releases and do the version management, similar to the vendordeps. You can see an example with BobTrajectory:


I’d also highly recommend JitPack. Assuming your project is already built with Gradle, it’s a totally drop-in solution. We use it for our library, ROOSTER. If you check the README there’s also a little bit more instruction on exactly how to use JitPack). And to stop this being a shameless plug of our library, I know of several other teams who use it in the same manner.

One minor caveat of JitPack is that it takes a few minutes to download when you request your library for the first time after pushing new code to GitHub, so it’s not ideal for rapid iteration of code. However, if your library is pretty much unchanging, then it works fantastically well. With some small additions to your buildscript in your library, you can additionally pull down source code and Javadoc JAR files (see lines 12-25 here) and get documentation for your library in your IDE of choice.