GradleRIO 2018 Kickoff Release

GradleRIO is a build system for FRC, and is now stable for the 2018 Kickoff.

GradleRIO supports WPILib and its tools, as well as third party libraries like CTRE Phoenix and the NavX Drivers automatically, downloading and managing their versions.

GradleRIO is highly expandable and customizable, and is currently trusted by over 100 teams worldwide to build and deploy their code. GradleRIO supports both C++ and Java (and other languages, too!), as well as a collection of IDEs like IntelliJ IDEA, Eclipse and Visual Studio. Since GradleRIO operates from the command line, you can even just use a normal text editor.

GradleRIO supports Shuffleboard, SmartDashboard and RIOLog from the command line, and will even install java on your RoboRIO for you.

Most builds complete in under 5 seconds, depending on your hardware.

If you’re savvy, you can even deploy to coprocessors using GradleRIO, or even have multiple codebases all active at once.

You can get GradleRIO now stable and ready for the 2018 Power Up Season here, and read some useful docs here. The 2019 Roadmap is available here.

As always, GradleRIO is a community project. We welcome your feature requests, bug reports and pull requests on the GradleRIO repository. Happy Coding!

I was testing this last night and it’s awesome! Thanks for putting this out and thanks for saving me from trying to compile Phoenix myself!

Jaci, this tool is amazeballs. Thank you!

Not a gradle guy, but very interested. Without any difficulty I have been able to use GradleRIO to build code from the command line, and I am a fan of VIM so I am off to the races, but some of the kids on our team seem to think that is pretty archaic. So I was hoping someone could walk me through setting up an Eclipse and IntelliJ project.

I tried

./gradlew eclipse

which generates an eclipse project; however, the project does not have the normal eclipse run options, did I miss a step?

With IntelliJ I am much closer

./gradlew idea

The project works and after a couple automatic clicks the gradle bar on the right works, but the code is still not a 100%. If open a source code file and try to “Go To Declaration” it does not find the code (which is there and build correctly).

I suspect I am missing something I should know, but I don’t use either of these environments except when mentoring and a couple quick searches led to results that need more contextual knowledge than I have, so I am asking here.

Thanks

Note that if you are compiling with JDK 9, you’ll need to add this to your build.gradle for your code to run:


compileJava {
    sourceCompatibility = 1.8
    targetCompatibility = 1.8
}

You still can’t use Java 9 language features or install 9 on the RoboRIO, but you can still compile with it.

I often don’t bother with gradle’s project file generation, I will import it as a gradle project in IntelliJ and I select auto-import, which often does the trick for me. This has worked well for me, ymmv.

Is this a class you wrote, or a library class (e.g. IterativeRobot)?

Is the import showing up correctly, or is showing red?

Usually when something like that happens I’ve found it is because IntelliJ and Gradle are not in sync.

A Build > Rebuild usually fixes it for me. When you import the project the first time, I’d recommend checking the “Use auto-import” option, which will automatically keep the two in sync.

Basic robot builder boilerplate. In this case a subsystem that is in the project.

Is the import showing up correctly, or is showing red?

Red

Usually when something like that happens I’ve found it is because IntelliJ and Gradle are not in sync.

A Build > Rebuild usually fixes it for me. When you import the project the first time, I’d recommend checking the “Use auto-import” option, which will automatically keep the two in sync.

I used auto-import and the build/re-build at least appears to work still showing red, still not able to go to places in the code.

Again this builds perfectly at the command line, so I know the code is fine (and very simple).

This is from our build.gradle file

def TEAM = 862
def ROBOT_CLASS = “org.usfirst.frc862.glitch.Robot”

Is it possible the there is some expectation about the class/package name?

Still showing red, but working well enough in IntelliJ. I had to select the src path and mark the directory as source root.

Now back to Eclipse.

Thanks for the help

Gradle doesn’t generate run configurations automatically, with gradle projects, it’s intended to use either the gradle plugin for said IDE, or to run from the command line. You can add your own run configurations, also.

As for imports showing in red, this usually happens when updating a library. Close your IDE, run ./gradlew cleanIdea idea (or the eclipse equivilent) and open it back up

I’m able to deploy my code, but the log keeps spewing out


Exception in thread "main" java.lang.UnsatisfiedLinkError: no wpilibJNI in java.library.path 
 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) 
 	at java.lang.Runtime.loadLibrary0(Runtime.java:870) 
 	at java.lang.System.loadLibrary(System.java:1119) 
 	at edu.wpi.first.wpilibj.hal.JNIWrapper.<clinit>(JNIWrapper.java:58) 
 	at edu.wpi.first.wpilibj.RobotBase.initializeHardwareConfiguration(RobotBase.java:173) 
 	at edu.wpi.first.wpilibj.RobotBase.main(RobotBase.java:192) 

I’m not on a beta team (not for lack of trying :frowning: ), so I don’t have access to the NI 2018 software and can’t update the RIO image. Basically I’m just taking a 2017 bot and hoping that ./gradlew deploy magically makes everything work for 2018 instantly. On the install page the only software I have to install as a Java team is the NI Update Suite (which is password locked), the radio utility (the board I’m using doesn’t have a radio on it so that’s not the problem), Java 8, Eclipse, and the WPI plugins. I’m assuming GradleRIO handles the WPI stuff, so is it just the NI suite or is there something else I’m missing?

I believe this is due to having an outdated RoboRIO image, since the new wpilibJNI is built with the 2018 Toolchain. I can verify Java seems to be operational on the new image.

If you run ./gradlew deploy -Pdeploy-dry, you can see all the libraries being sent over. Grep’ing for libwpilibJNI.so in this log should yield a result, verifying it was deployed.

It actually does not. Full result from ./gradlew deploy -Pdeploy-dry:

> Task :discoverRoborio 
Dry Run! Using roborio-449-FRC.local for target roborio
-> Simulating timeout delay 3s (disable with -Pdeploy-dry-instant)

> Task :deployFrcJava 
  -> FRCJavaArtifact[frcJava]
    ~ mkdir -p /home/lvuser
    -C-> . /etc/profile.d/natinst-path.sh; /usr/local/frc/bin/frcKillRobot.sh -t 2> /dev/null @ /home/lvuser
      ~ cd /home/lvuser; . /etc/profile.d/natinst-path.sh; /usr/local/frc/bin/frcKillRobot.sh -t 2> /dev/null
    ~ mkdir -p /home/lvuser
    -F-> build/libs/robot-in-a-box-1.0.jar -> robot-in-a-box-1.0.jar @ /home/lvuser
    ~ mkdir -p /home/lvuser
    -C-> echo '/usr/local/frc/JRE/bin/java -Djava.library.path=/usr/local/frc/lib/   -jar /home/lvuser/robot-in-a-box-1.0.jar ' > /home/lvuser/robotCommand @ /home/lvuser
      ~ cd /home/lvuser; echo '/usr/local/frc/JRE/bin/java -Djava.library.path=/usr/local/frc/lib/   -jar /home/lvuser/robot-in-a-box-1.0.jar ' > /home/lvuser/robotCommand
    ~ mkdir -p /home/lvuser
    -C-> chmod +x /home/lvuser/robotCommand; chown lvuser /home/lvuser/robotCommand @ /home/lvuser
      ~ cd /home/lvuser; chmod +x /home/lvuser/robotCommand; chown lvuser /home/lvuser/robotCommand
    ~ mkdir -p /home/lvuser
    -C-> chmod +x robot-in-a-box-1.0.jar; chown lvuser robot-in-a-box-1.0.jar @ /home/lvuser
      ~ cd /home/lvuser; chmod +x robot-in-a-box-1.0.jar; chown lvuser robot-in-a-box-1.0.jar
    ~ mkdir -p /home/lvuser
    -C-> sync @ /home/lvuser
      ~ cd /home/lvuser; sync
    ~ mkdir -p /home/lvuser
    -C-> . /etc/profile.d/natinst-path.sh; /usr/local/frc/bin/frcKillRobot.sh -t -r 2> /dev/null @ /home/lvuser
      ~ cd /home/lvuser; . /etc/profile.d/natinst-path.sh; /usr/local/frc/bin/frcKillRobot.sh -t -r 2> /dev/null


> Task :deployJre 
  -> FileArtifact[jre]
   -> OnlyIf Check
    ~ mkdir -p /tmp
    -C-> if  -f "/usr/local/frc/JRE/bin/java" ]]; then echo OK; else echo MISSING; fi @ /tmp
      ~ cd /tmp; if  -f "/usr/local/frc/JRE/bin/java" ]]; then echo OK; else echo MISSING; fi
   -> DRY
  JRE Missing! Deploying RoboRIO Zulu JRE....
    ~ mkdir -p /tmp
    -F-> /C:/Users/noahg/.gradle/gradlerio/jre/zulu/JreZulu_18u131.ipk -> zulujre.ipk @ /tmp
    ~ mkdir -p /tmp
    -C-> opkg install /tmp/zulujre.ipk; rm /tmp/zulujre.ipk @ /tmp
      ~ cd /tmp; opkg install /tmp/zulujre.ipk; rm /tmp/zulujre.ipk
  JRE Deployed!


> Task :deployNativeLibs 
  -> FileCollectionArtifact[nativeLibs]
    ~ mkdir -p /usr/local/frc/lib
    ~ mkdir -p /usr/local/frc/lib
    -C-> ldconfig @ /usr/local/frc/lib
      ~ cd /usr/local/frc/lib; ldconfig


> Task :deployNativeZips 
  -> FileCollectionArtifact[nativeZips]
    ~ mkdir -p /usr/local/frc/lib
    ~ mkdir -p /usr/local/frc/lib
    -C-> ldconfig @ /usr/local/frc/lib
      ~ cd /usr/local/frc/lib; ldconfig



BUILD SUCCESSFUL in 4s
7 actionable tasks: 5 executed, 2 up-to-date


Here’s the repo and here’s the build.gradle.

If you haven’t listed WPILib as a dependency, GradleRIO won’t try to deploy WPILib.

https://github.com/blair-robot-project/robot-in-a-box/blob/update_libraries/build.gradle#L29-L31

It should have a “compile wpilib()” line in there. A transitive, prebuilt WPILib doesn’t include the native libraries, so you need that line on the project that actually does the deploying.

NOTE: Release 2018.01.06b has been released. It includes an updated Shuffleboard and updated RoboRIO Java Runtime. It’s highly recommended to update before kickoff (and prior to imaging your rio, if you’re a java team).

The new JRE should have less memory usage overall.

This is good news. We’d run into memory issue with deploys with the previous JRE and had started profiling it with YourKit to figure out what was going on.

1 Like

Thanks, that switched the error to

Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/local/frc/lib/libwpilibJNI.so: libRoboRIO_FRC_ChipObject.so.18: cannot open shared object file: No such file or directory 
 	at java.lang.ClassLoader$NativeLibrary.load(Native Method) 
 	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929) 
 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1847) 
 	at java.lang.Runtime.loadLibrary0(Runtime.java:870) 
 	at java.lang.System.loadLibrary(System.java:1119) 
 	at edu.wpi.first.wpilibj.hal.JNIWrapper.<clinit>(JNIWrapper.java:58) 
 	at edu.wpi.first.wpilibj.RobotBase.initializeHardwareConfiguration(RobotBase.java:173) 
 	at edu.wpi.first.wpilibj.RobotBase.main(RobotBase.java:192) 

which looks like it’s because I don’t have the firmware update. Thanks for the help! Is there a way to separate out “I want the roborio to have WPILib installed” and “the code compiled by this gradle project depends on WPILib?” I could easily be wrong here, but doesn’t having WPILib as an uneeded dependency dependency increase the jar size and therefore deploy time?

Yep, FRC_ChipObject is included with the NI Update. Once you get the kickoff release, it should run with no troubles.

There is a way to deploy *just *the WPILib native libraries, shown below:


dependencies {
    nativeZip wpilibJni()
}

This isn’t recommended though, since it has the possibility that your external library has one version of WPILib, and your deployed native libraries has another.