The Ant scripts we have don't include anything but .class files in the jar it builds. That's fixable, look in the "jar" task of
wherever/wpilib/java/current/ant/build.xml, and we see:
Code:
<fileset dir="${build.dir}" includes="**/*.class"/>
Adding a line like this:
Code:
<fileset dir="${src.dir}" includes="**/*.properties"/>
should get your file into the jar, but will be fragile (you'll need to customize every machine you deploy from, and your change will get lost everytime you take an update of the Eclipse plugins). I put a feature request in for this to get made part of wpilib.
I think you touched on what may be a show stopper: as I recall, the runtime configuration we have is missing a lot of stuff necessary to make log4j basic configuration work (missing introspection and some of the XML apis, as I recall). Try it, if it works, let us know!
You may need to go to full programmatic configuration to use log4j.
You may want to consider using java.util.logging; it'll work out of the box. I don't like the API, but it's a low hassle way to get what you want. You can programmatically config it pretty easily. We did it last year: take a look at our last year's code
https://github.com/FRC3620/FRC3620_2015_AverageJava
(look at the EventLogger class), you are welcome to the relevant bits.
We actually didn't even use the j.u.l API, just the logging framework, we used slf4j for the logging API, so we need the slf4j-api jar. The build.properties that make that happen in 2015 was uglier than it needs to be anymore. Use the new way('userLibs').
We ended up configuring the appenders (well, handlers in j.u.l) once (we sent INFO on up to the console, and everything went to log file on the roboRIO). We set the logging level for each logger as created, so every command/subsystem that creates a logger sets the level of logging it wants at the time it does the creation. Not the way I like to do things, but it kept programmers from dancing on each other's setting in a master logging config.