Latest strongback version ships with old version of the CTRE library

[mrwaldron]

The CTRE download url changed mid January '17 to be versioned, eg from:
http://www.ctr-electronics.com/downloads/lib/CTRE_FRCLibs_NON-WINDOWS.zip
to:
http://www.ctr-electronics.com/downloads/lib/CTRE_FRCLibs_NON-WINDOWS_v4.4.1.14.zip

To add to the confusion, the name of the libraries has changed from:
TalonSRXLibJava.jar
libTalonSRXLib.so
to:
CTRLib.jar
libCTRLibDriver.so

At minimum an update is needed to ctre.download.url in build.properties and jarNames in build.xml

While I suspect having multiple different .so files is fine, having multiple conflicting copies of the .jar file with the same .class files in them will presumably cause the JRE to load the first found causing the old (and possibly buggy) version to be loaded instead of the carefully installed CTRLib.jar.

We discovered this when after installing strongback our code would fail with missing method exceptions at runtime on the robot because we used new methods only available in the later Talon library versions, presumably because we had both TalonSRXLibJava.jar (from strongback) and CTRLib.jar (pre-dating strongback).

I would imagine that other teams will discover this painfully and not necessarily know how to resolve it by deleting one of the libraries.

Possible fixes would include:

1. Next version of strongback-java ships both .jar files, both having the same content as the CTRLib.jar. A TalonSRXLibJava.jar.README file also shipped and installed in the same directory would help to explain away some of the confusion until updated cli's are rolled out.
   While potentially confusing, but would work out of the box without a cli update. Seems to be the most reliable option.

2. Next version of strongback-java ships with updated ant scripts that checks for and warns the user that both .jar files are installed and that the TalonSRXLibJava.jar and .so files should be manually removed.

3. Same as number 2 but automatically delete the older libraries in the ant scripts.

4. Update strongback-cli to remove user libraries that have dependency.SameVersion==true on version uninstall.
   Requires a strongback-cli update before it'll work out of the box, so it's likely to be missed by current users.

5. Ship new files with release notes warning users to delete the old files. Suspect most users won't read them and it'll cause frustration down the line.

?) Others?

Possible solutions for making this easier next time.

A) Option 4 above - update the cli to do remove user libraries on uninstall if they are the same as the installed version. Only works if strongback installed the old library in the first place.

B) Update the releases to have a flag containing the minimum version of the cli that they can be installed by. Install attempts by an old cli version would cause an error and instructions on how to update the cli.

C) Have the releases contain some script that was run on release install and removal to do cleanups like this. Only helps after a cli release.

D) Update strongback-cli to have special handling for the next release and following releases to remove the problematic libraries. Ugh.

?) Others?

I'd suggest that option 1 (ship both files with the same content) with a warning in the release notes would be a reasonable first step.

Then say option A (remove user libraries on uninstall) and option B (minimum cli version to install some strongback-java versions) would help next time something unexpected changes.

Thoughts?

All CTRE versions can be found here: http://www.ctr-electronics.com//downloads/lib/

The RELEASE_NOTES.txt from the latest release contains the features and fixes in the later releases.

[SUPERCILEX]

See #92 (comment) if you're using Gradle.

[agausmann]

Sorry that you have had no response; I've not been able to get in contact with @rhauch through my own channels either. He is the only project member with write access at the moment. Unfortunately, we might have to abandon this repository and fork it elsewhere.

[rhauch]

I've not been able to keep up with this due lack of spare time, but I'm happy to give commit privilege to others, especially @agausmann, or even turn this over to others. (BTW, I've not received your emails!) I'm also hoping to get some time over the holiday break to catch things up. Our team is not part of the Beta program this year and I don't have access to the latest beta, so anyone who is that can help would be greatly appreciated.

[agausmann]

Ahhhh, I didn't even think about email, I just tried to DM you on Slack. Sorry about that!

I'd be willing to help maintain this project, but I don't have access to any FRC hardware anymore to test changes. I'll see if I can get in touch with a local team (Rolla) and get them involved with Strongback.