I am wondering how to commit to github a referenced library for an eclipse robot project with the rest of the project so that when someone pulls the code/imports the project for the first time, they don’t have to setup any libraries or have issues with missing a reference.
What we do is commit the robot eclipse project to github, and people pull it. This has worked fine in the past because everyone has the WPILibrary plugins installed. Now we are using Pathfinder for some motion profiling stuff, and when people import the project it doesn’t work because they don’t have the library.
Could someone help me set this up correctly / explain the correct way to manage library dependencies? The behavior that I desire is for someone to be able to import the project into eclipse and not need to mess with any library stuff.
What you refer to is what I know in industry as “Dependency Management” - A mechanism to automatically say “this release of my software requires these releases of this other software in a specific location”. Gradle, Maven, or Ivy are all possibilities, but all more or less require that the other libraries (CTRE, WPIlib, etc.) also have some artifacts to reference their releases. I don’t think that’s true right now, but I also haven’t looked too hard.
We got around it (mostly) last year by simply copying static versions of all the .jar files from other libraries into our repo, and then modifying the Ant build.xml’s slightly to pull from our custom-area. It wasn’t pretty, but it made sure I knew exactly what CTRE version was going to deployed, no matter which computer was being used. I don’t think we can get around the WPILib install easily since that adds extra buttons in eclipse, but the other 3rd party libraries will probably get similar treatment this coming year.
I provided feedback to some FRC channels that it would be nice to use Gradle or similar to help ensure each software build by each team gets done with the expected versions of external software. It can also be used to help team ensure all their versions are up-to-date pre-competition. It’s not a huge issue now, but as the number of 3rd-party libraries expand, it will become harder and harder to manage by hand.
I would create a folder for 3rd party libraries within your project and then put Pathfinder and any other libraries in there. When you commit and push, the library should be committed and pushed as long as none of the files needed are ignored by the .gitignore.
How can I make eclipse use a relative path to mark the location of those libraries? Normally it uses absolute path when I go into “manage build path” then “add library” or “external jar” or whatever.
GradleRIO manages this for both C++ and Java. WPILib publishes their own stuff to maven, although CTRE and NavX don’t. For CTRE and NavX, I host my own maven that fetches regularly from both vendors, and is what GradleRIO runs in the backend.
If you start pulling in external libraries, I also definitely recommend checking out GradleRIO. ANT (the build system that FRC projects use by default) just isn’t designed for proper dependency management.
Static JAR files can be fine for more or less short term projects like we use in FRC, but you don’t have very good versioning with those.
Gradle is also becoming more and more prevalent in the industry, so learning it is a good exercise for students.
Another bump for GradleRIO. The combination of custom arguments and multi-project setup was a gamechanger.
Now the display kids can go nuts with 3rd-party libraries and use the same common libraries as the robot without ridiculous copy/paste management of the jars.