So this year, I decided to add a .json file to hold the configuration for our robot.
Ideally, I’d like to use the following file structure:
src/main/java/<robot package then code here>
But then cfg.json didn’t appear anywhere in the compiled .jar
So I moved cfg.json to the robot package (com.usfirt.frc.team449.robot) but it still won’t appear in the compiled jar.
So I decided to look up general ways to add non-source files to the jar, but the change that this requires would have to be in the build.xml that wpilib generates via the plugin (I believe that line 94 of that build.xml taht only copies .class files to the jar would do that).
I have noticed on other threads with people asking how to find a file on the roborio, that it would be better to scp or ftp the file into /home/lvuser. Is there any way to automatically do that during the build script (without copying half the wpilib build.xml, redundantly resolving the ip of the roborio and then ssh’ing)?
Do you know if i can add the SSHing as something that can be done on every deploy, but also when i just need to update the file (for tuning, as you mentioned).
I have tried setting the resources folder as a source (as well as just putting the json in alongside the source files) but it doesn’t end up in the jar and my program can’t find it.
So last year, when our team switched to java, we used a single java class with constants. However, that file (along with the file structure) was a mess to parse as the only way to sort the variables was by prefixing their name with their subsystem or whatever (example)
This year I worked on revamping the file system to enable code reuse by creating self-sufficient subsystem that could theoretically simply be added to a new robot project that has those subsystems, and only some configuration would have to be made.
The problem now is that each subsystem has its own map. Now our configuration is all over the place.
To solve this problem I created a program that parses the maps to create a single json file skeleton, that once trimmed and filled in (eventually automatically) will contain all of the configurations in one place, and ultimately would make finding conflicting ports or wrong values significantly easier.
TL;DR the json should, in the end, make configuration significantly easier and allow for code reuse structure in code.