[Help] Including non source files in compiled jars (or alternatives)

Technical Java
1

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>
src/main/resources/cfg.json

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)?

Currently our working solution is running a short program to print the cfg in one line so we can paste it into a variable used as a fallback when the file isn’t fount in code.

2

The reason SSHing to the RIO is done is because the file will be some small config file which will take ~1 second to edit or ~30 seconds to redeploy. Good if your tuning a PID loop or something.

If I had to guess (the robot is currently being worked on… and is written in Python now…)

Right click on your project in Eclipse and go to Properties -> Java Build Path -> Source and add the “yourProjectName/resources” folder

3

What is the advantage of including a JSON file in the jar, as opposed to a java class with constants?

4

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.

5