Code Monkey home page Code Monkey logo

gradlerio's Introduction

CI

GradleRIO

GradleRIO is a powerful Gradle Plugin that allows teams competing in the FIRST robotics competition to produce and build their code.

GradleRIO works with Java and C++ (and others!), on Windows, Mac and Linux. GradleRIO automatically fetches WPILib, Tools, and Vendor Libraries.

For 2019+, GradleRIO is the official build system for the FIRST Robotics Competition! The officially supported IDE is Visual Studio Code (VS Code), using the WPILib Extension.

frc-docs is the best place for documentation: https://docs.wpilib.org/en/stable/

Other IDEs like IntelliJ IDEA, Eclipse, Visual Studio, and CLion are also supported, unofficially. You may also use this tool exclusively from the command line, allowing use of any IDE or text editor (like Sublime Text, Atom or Vim).

Getting Started - Creating a new project

With Visual Studio Code (recommended)

For getting started with VS Code, please see the frc-docs documentation: https://docs.wpilib.org/en/stable/docs/zero-to-robot/introduction.html

Without Visual Studio Code

Follow the installation instructions on frc-docs: https://docs.wpilib.org/en/stable/docs/zero-to-robot/step-2/wpilib-setup.html Note that the offline installer isn't required, but will save you a ton of time and is highly recommended.

WPILibUtility Standalone Project Builder WPILib provides a standalone project builder that provides the same interface as VS Code, without having to use VS Code.

If you've used the installer, find and run wpilibutility in C:\Users\Public\wpilib\<YEAR>\utility (windows), or ~/wpilib/<YEAR>/utility(mac/linux). Note that mac users will have to extract the .tar.gz file, then run. Alternatively, download it from the VSCode-WPILib releases, extract it, and run it: https://github.com/wpilibsuite/vscode-wpilib/releases

Use the WPILib Utility whenever you want to create a new project.

Adding Vendor Libraries

With Visual Studio Code

Open the command palette with CTRL + SHIFT + P, or by clicking the WPILib icon. Open WPILib: Manage Vendor Libraries, Install new libraries (online), and paste the vendor-provided JSON url.

Without Visual Studio Code

Create a folder vendordeps in your project directory if it doesn't already exist. Download the JSON file from the vendor-provided URL, and save it to the vendordeps folder. This can be done by running ./gradlew vendordep --url=<vendor url here> in a project.

Commands

Windows Users: It is recommended to use Powershell instead of CMD. You can switch to powershell with powershell

General

  • ./gradlew build will build your robot code (and run unit tests if present).

  • ./gradlew deploy will build and deploy your code.

  • ./gradlew installRoboRioToolchain will install the C++ Toolchains for your system (required for C++).

Tools

  • ./gradlew Glass will launch Glass, a data visualization tool similar to the SimGUI.
  • ./gradlew ShuffleBoard will launch Shuffleboard, the 2018 replacement for SmartDashboard.
  • ./gradlew SmartDashboard will launch Smart Dashboard (note: SmartDashboard is legacy software, use ShuffleBoard instead!).
  • ./gradlew RobotBuilder will launch Robot Builder, a tool for generating robot projects and source files.
  • ./gradlew OutlineViewer will launch Outline Viewer, for viewing NetworkTables.
  • ./gradlew PathWeaver will launch PathWeaver, a tool for generating motion profiles using WPILib's trajectories and splines.

At Competition? Connected to the Robot? Run with the --offline flag. e.g. ./gradlew deploy --offline

IDE Support

Visual Studio Code:

VS Code is fully supported by GradleRIO for FRC. To use it, use the WPILib VS Code extension. See frc-docs for instructions.

IntelliJ IDEA:

IntelliJ IDEA support is unofficial in the FRC sense, but is well supported by the Gradle team. CSA Support isn't guaranteed, so make sure you're prepared to fix any issues yourself if you're at an event.

To import a gradle project into IntelliJ IDEA please do one of the following:

  • In the welcome screen click Import Project and select the build.gradle file of the project.
  • Click Open on the welcome screen or File - Open while you have another project open and select the build.gradle file of the project. IntelliJ will then prompt you if you would like to open it as a project, click Open as Project

IntelliJ may ask to import the Gradle project in the bottom right of the IDE, simple click Import Changes to import it.

Please see the IntelliJ IDEA help page on gradle for help: https://www.jetbrains.com/help/idea/gradle.html

Eclipse

Eclipse support is unofficial in the FRC sense, but is well supported by the Gradle team. CSA Support isn't guaranteed, so make sure you're prepared to fix any issues yourself if you're at an event. Eclipse is only supported for JAVA (not C++)

First install buildship, the gradle plugin made by Eclipse for the Eclipse IDE. Installation instructions can be found here: https://github.com/eclipse/buildship/blob/master/docs/user/Installation.md

Once installed, navigate to File - Import… - Gradle and select Gradle Project.

Press the Next > button, then specify the root directory of the project. Press Finish once to finish the import, and Finish again to confirm it.

Please see the buildship github page for help (specifically the user documentation and the forums): https://github.com/eclipse/buildship

Visual Studio 2017 Community / Full (not Visual Studio Code)

VS2017 support is unofficial in the FRC sense, but is well supported by the Gradle team. CSA Support isn't guaranteed, so make sure you're prepared to fix any issues yourself if you're at an event.

To start with, you must apply the visual-studio plugin to build.gradle. In your build.gradle, put the following code in the plugins {} block.

plugins {
    id 'visual-studio'
}

Finally, you can generate and open your solution with the following command:

  • ./gradlew openVisualStudio will generate IDE files for VS2017 (C++) and open Visual Studio.

Please see the gradle guide on building native software for help: https://docs.gradle.org/current/userguide/native_software.html#native_binaries:visual_studio

Upgrading

To upgrade your Gradle project (and GradleRio plugin) from one year to the next follow the Importing a Gradle Project instructions in the WPILib Documentation.

For mid-season updates to GradleRio, edit build.gradle and replace the version in the plugin line (only change the GradleRIO line):

plugins {
    // ... other plugins ...
    id "edu.wpi.first.GradleRIO" version "REPLACE ME WITH THE LATEST VERSION"
}

The latest version can be obtained from here: https://plugins.gradle.org/plugin/edu.wpi.first.GradleRIO

Using alternate garbage collector

GradleRIO has built in settings for several different garbage collectors. The G1 Garbage Collector was used for 2023. The Serial Garbage Collector is used for 2024. A list of all Garbage Collectors and settings that GradleRIO has built-in support for setting is available at: https://github.com/wpilibsuite/GradleRIO/blob/main/src/main/java/edu/wpi/first/gradlerio/deploy/roborio/GarbageCollectorType.java. To use another Garbage Collector, in the FRCJavaArtifact block, add gcType = and set it to the value found in the GarbageCollectorType enum.

The Other gcType can be used for complete customization

  1. Set gcType = 'Other' in the FRCJavaArtifact block
  2. Add the appropriate jvmArg for the Garbage Collector and settings in the FRCJavaArtifact. For the default G1 settings:
    jvmArgs.add("-XX:+UseG1GC")
    jvmArgs.add("-XX:MaxGCPauseMillis=1")
    jvmArgs.add("-XX:GCTimeRatio=1")
    

Using GradleRIO custom builds

To use a custom build of GradleRIO in a robot project, the build must be published.

  1. Update the version in gradle.properties so that GradleRIO won't overwrite an existing version.
  2. Execute .\gradlew publishToMavenLocal
  3. Update the GradleRIO version in your robot projects build.gradle to the version you defined in GradleRIO gradle.properties.
plugins {
    // ... other plugins ...
    id "edu.wpi.first.GradleRIO" version "REPLACE ME WITH THE PUBLISHED VERSION"
}

gradlerio's People

Contributors

333fred avatar arvind-srinivasan avatar austinshalit avatar bob80333 avatar calcmogul avatar carbotaniuman avatar daltz333 avatar floogulinc avatar fovea1959 avatar ggoebel avatar itayziv avatar jacibrunning avatar jwhite66 avatar kevin-oconnor avatar peterjohnson avatar prateekma avatar redrield avatar ryanhir avatar sciencewhiz avatar spacey-sooty avatar starlight220 avatar supercilex avatar thadhouse avatar theosotr avatar williamkluge avatar zhiquanyeo avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

gradlerio's Issues

nativeZip behavior changed

nativeZip complains that it can't resolve cscore-1.0.2-athena-uberzip.zip, we used to be able to placate it with a copy in libs/ and using --offline but it now complains again.

Guidance on adding Log4j

Hi, I've been using this project successfully for building, deploying, and watching riolog. I'm not at all familiar with Gradle though, but would like to use log4j for logging on the roborio. Would you be willing to give me some pointers on how to add external dependencies? The basic stumbling block I'm having is just that the log4j JARs aren't getting copied to the Rio on deploy. This is probably super straight-forward, but I'm slow like molasses reading and writing Gradle, right now.

Unsupported major.minor version

Every time I try to use any gradlew command, I get a crash.

$ ./gradlew wpi

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/student/Downloads/GradleRIO/build.gradle' line: 22

* What went wrong:
A problem occurred evaluating root project 'GradleRIO'.
> jaci/openrio/gradle/GradleRIO : Unsupported major.minor version 52.0

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 9.695 secs

I get this even if I run gradlew without any arguments.

Dependencies not resolving

I'm trying to set up GradleRIO but whenever I run ./gradlew it errors saying

I tried manually adding dependencies but ./gradlew doesn't seem to look at them.

Don't default to dynamic dependency versions

Defaulting to "+" for all dependency versions is dangerous, as it can pull in new versions that cause breaking changes.

Two great examples of this are #45 and #43 , both of which caused builds to fail due to breaking changes in the dependencies. If teams are using GradleRIO with the default configuration of not specifying the versions themselves, they will be completely unaware that the version is changing and will simply see a failed build.

Ideally teams would be forced to declare the dependencies themselves, but I definitely appreciate the convenience of bundling everything together under methods like wpilib().

A compromise might be to add a version to the convenience methods, such as wpilib("2017.3.1"), and split out the different components more (e.g. openCv("3.1.0")). This would make the versioning explicit and keep all dependency information in the dependencies closure instead of putting some of it in the WPI plugin configuration. Doing so would also make it more obvious what dependencies are pulling in, when some like open CV are currently more or less hidden unless the team knows where in the GradleRIO repository to dig around.

If the goal is to encourage keeping those libraries up to date, we could output an info/warning message as appropriate when new versions become available. As a bonus, that wouldn't require any server-side code to report out of date information as was mentioned in #43.

I'd be happy to submit a PR if we can agree on an approach.

Incompatibility with Eclipse Plugins

Due to the single admin SSH session, the frcUserProgram file conflicts with that being deployed by the eclipse plugins, causing a potential deadlock in the deploy process since frcKillRobot.sh doesn't affect other users' owned processes

InputStream is closed

Gradle is constantly unable to deploy to the RoboRIO. I am building before deploying.

Failed SFTP PUT: /Users/64008508/GitHub/Titanium/build/libs/Titanium.jar -> Remote3:/home/lvuser

1 of 2 session (50%) failed

Session #2 failed: java.lang.RuntimeException: java.lang.RuntimeException: org.hidetake.groovy.ssh.operation.SftpFailureException: Failed SFTP PUT: /Users/64008508/GitHub/Titanium/build/libs/Titanium.jar -> Remote3:/home/lvuser: (SSH_FX_FAILURE: An error occurred): java.io.IOException: inputstream is closed

stacktrace

update CTRLib?

Currently it seems like http://dev.imjac.in/maven/ only has CTRLib v 4.4.1.9, there has been a 4.4.1.10 and a 4.4.1.11 out since then, can we get those added to maven repo?

Thanks for all you do!

Unable to build static libarary

When compiling a static library, static archiving fails with the following error on Windows:

C:\Users\akemp\.gradle\gradlerio\toolchains\bin\arm-frc-linux-gnueabi-ar.exe: unrecognized option `--sysroot'
Usage: C:\Users\akemp\.gradle\gradlerio\toolchains\bin\arm-frc-linux-gnueabi-ar.exe [emulation options] [-]{dmpqrstx}[abcDfilMNoPsSTuvV] [--plugin <name>] [member-name] [count] archive-file file...
       C:\Users\akemp\.gradle\gradlerio\toolchains\bin\arm-frc-linux-gnueabi-ar.exe -M [<mri-script]
 commands:
  d            - delete file(s) from the archive
  m[ab]        - move file(s) in the archive
  p            - print file(s) found in the archive
  q[f]         - quick append file(s) to the archive
  r[ab][f][u]  - replace existing or insert new file(s) into the archive
  s            - act as ranlib
  t            - display contents of archive
  x[o]         - extract file(s) from the archive
 command specific modifiers:
  [a]          - put file(s) after [member-name]
  [b]          - put file(s) before [member-name] (same as [i])
  [D]          - use zero for timestamps and uids/gids
  [U]          - use actual timestamps and uids/gids (default)
  [N]          - use instance [count] of name
  [f]          - truncate inserted file names
  [P]          - use full path names when matching
  [o]          - preserve original dates
  [u]          - only replace files that are newer than current archive contents
 generic modifiers:
  [c]          - do not warn if the library had to be created
  [s]          - create an archive index (cf. ranlib)
  [S]          - do not build a symbol table
  [T]          - make a thin archive
  [v]          - be verbose
  [V]          - display the version number
  @<file>      - read options from <file>
  --target=BFDNAME - specify the target object format as BFDNAME
 optional:
  --plugin <p> - load the specified plugin
 emulation options:
  No emulation specific options
C:\Users\akemp\.gradle\gradlerio\toolchains\bin\arm-frc-linux-gnueabi-ar.exe: supported targets: elf32-littlearm elf32-bigarm elf32-little elf32-big plugin srec symbolsrec verilog tekhex binary ihex



FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':createFrcUserProgramStaticLibrary'.
> A build operation failed.
      Static library archiver failed while archiving libfrcUserProgram.a.
  See the complete log at: file:///C:/Users/akemp/Downloads/cpp/build/tmp/createFrcUserProgramStaticLibrary/output.txt

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

* Get more help at https://help.gradle.org

BUILD FAILED in 11s
4 actionable tasks: 1 executed, 3 up-to-date

Bug can be reproduced by changing NativeExecutableSpec to NativeLibrarySpec in quickstart cpp project and building on Windows.

For some reason, compilation only fails on Windows, it appears to work fine on Linux.

Allow user to specify WPI options such as version and maven release type

We now have a versioning plugin for WPILib, which takes care of figuring out what repository to use. I suggest that you move to using it. You can find the plugin here: https://plugins.gradle.org/plugin/edu.wpi.first.wpilib.versioning.WPILibVersioningPlugin. I don't believe that you can actually apply it to the script yourself, as you can't modify the buildscript after being loaded. But you can apply the plugin to the example script and set up the plugin correctly:

WPILibVersion {
    releaseType = official
}

This will make sure that you are using the correct repo, and allow others to use the development repo easily if they want to.

Revert CTRE Version

It looks like GradleRIO is updating the TalonSRX dependency to an alpha version (5.0.2.1) that has code-breaking API changes. Is there any way to specify that I want to use version 4.4.1.14 of the CTRE jar?

Thanks!
P.S. This project is a great contribution to the community - very much appreciated!

2017 WPILib Update

Hey Jaci,

No huge rush, but would you mind updating your repo for the 2017 wpilib updates?

We're currently working off the 2016 version, but we're waiting on the 2017 update for the actual robot code.

Thanks!

PS. I plan to re-write the documentation on how to get started for this year too. I'll probably do it in LaTeX for easier updating and community input.

nativeLib dependency deploy error

Deploy pipeline only supports 1 and only 1 file in each nativeLib dependency. If fileTree is used and no file exists, a nullpointer exception is thrown.

Thanks to team 4711 for bringing this issue to my attention on the FRC discord. It's pending a fix in the newer release of GradleRIO that's being worked on in the branch "refresh2018"

Unable to find target RIO when able to ping every other way

When testing to see if it was my computer that was having troubles connecting to the robot for purposes of code deploy, I wanted to see if GradleRIO would be able to determine the RIO address. I copied the quickstart buildscript into an empty directory structure and ran gradle discoverRoborio. The command came back saying that it was unable to discover the target, and was aborting because of a config choice.

I was able to find the RIO's mDNS in avahi-browse -alr. I was able to ping the robot's IP (in this case 10.40.69.2), and I was able to see content dispatched from its web dashboard (Telling me to get silverlight in this case). So the problem must lie with GradleRIO.

Update to Gradle 4.3

Gradle 4.3 will automatically apply the build-scan plugin when needed, as well as adds setTargets() on the toolchain model (which will be more useful in the EmbeddedTools backend).

C++ also gets build cache support (experimental)

Migration guide for earlier 2017 versions?

My robot project is on 2017.1.5 and I'd like to migrate it to the new 2017.11.27 version in preparation for 2018, but the configuration layout of build.gradle appears to be completely different such that a simple version adjustment won't suffice.
Importantly, I'm not sure how to set parameters such as rioIP / port / host in the new syntax, which seems to take up a lot more space than the old syntax.

OpenCV Native libraries could not be loaded

I am using 2017.2.3. I have redeployed and reimaged.

OpenCV Native Libraries could not be loaded.
Please try redeploying, or reimage your roboRIO and try again.
java.lang.UnsatisfiedLinkError: no opencv_java320 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.RobotBase.initializeHardwareConfiguration(RobotBase.java:181)
	at edu.wpi.first.wpilibj.RobotBase.main(RobotBase.java:194)
********** Robot program starting **********
Error at edu.wpi.first.wpilibj.RobotBase.main(RobotBase.java:249): ERROR Unhandled exception: java.lang.NullPointerException at [org.usfirst.frc.team1018.lib.util.MultipleJoystickButton.<init>(MultipleJoystickButton.java:15), org.usfirst.frc.team1018.robot.OI.<init>(OI.java:24), org.usfirst.frc.team1018.robot.OI.getInstance(OI.java:51), org.usfirst.frc.team1018.robot.Robot.robotInit(Robot.java:47), edu.wpi.first.wpilibj.IterativeRobot.startCompetition(IterativeRobot.java:64), edu.wpi.first.wpilibj.RobotBase.main(RobotBase.java:247)]
WARNING: Robots don't quit!
---> The startCompetition() method (or methods called by it) should have handled the exception above.
NT: server: client CONNECTED: 10.10.18.20 port 56381

Edit: I just realized the error after "Robot program starting" is mine, I'm referring to the one above it.

Code not deploying

I'm trying to deploy my code to the RoboRIO using this plugin, but whenever I try to, it always gives me this error.

http://cl.ly/Zc88

The RoboRIO is connected and I can access it's webpage at roborio-xxxx.local

Talon SRX path blocked by firewalls

I'm a mentor at a US high school. The site that the Gradle script tries to copy the Talon SRX files from is in India (based on the URL). That site is blocked by the school's firewall (as are a large number of other sites). Are there any other locations that we can the Maven-ized version of this? And, how would we set that up? We are Gradle noobs.

FRC 2017. Using IntelliJ on Windows, Mac and Linux. Or at least trying to...

Support for directory-based structure

GradleRIO should drop file-based project structure support when generating a new project and instead use directory-based. This would make it easier for version control to manage, as files are split up into smaller segments.

Cannot version pin for CTRE library versions lower than 5.0

I've been working on getting our local projects updated to the latest GradleRIO. I was trying to version pin our project to the old TalonSRX libraries until they complete the new Phoenix framework but ran into some trouble when specifying the library versions in the build.gradle. Here's the exact error I got:
Could not find openrio.mirror.third.ctre:CTRE-phoenix-java:4.4.1.14. Searched in the following locations: http://first.wpi.edu/FRC/roborio/maven/release/openrio/mirror/third/ctre/CTRE-phoenix-java/4.4.1.14/CTRE-phoenix-java-4.4.1.14.pom http://first.wpi.edu/FRC/roborio/maven/release/openrio/mirror/third/ctre/CTRE-phoenix-java/4.4.1.14/CTRE-phoenix-java-4.4.1.14.jar http://dev.imjac.in/maven/openrio/mirror/third/ctre/CTRE-phoenix-java/4.4.1.14/CTRE-phoenix-java-4.4.1.14.pom http://dev.imjac.in/maven/openrio/mirror/third/ctre/CTRE-phoenix-java/4.4.1.14/CTRE-phoenix-java-4.4.1.14.jar https://raw.githubusercontent.com/Open-RIO/Maven-Mirror/master/m2/openrio/mirror/third/ctre/CTRE-phoenix-java/4.4.1.14/CTRE-phoenix-java-4.4.1.14.pom https://raw.githubusercontent.com/Open-RIO/Maven-Mirror/master/m2/openrio/mirror/third/ctre/CTRE-phoenix-java/4.4.1.14/CTRE-phoenix-java-4.4.1.14.jar

The only repositories out of these that the CTRE libraries are in is dev.imjac.in and the Maven-Mirror repository. The GitHub based Maven-Mirror seems to only have the newest CTRE libraries (5.0+) so trying to use older versions with that repository is pointless. The dev.imjac.in repository does have the older versions of the CANTalon library, but GradleRIO seems to be using the wrong repository path to find them. While GradleRIO searches in http://dev.imjac.in/maven/openrio/mirror/third/ctre/CTRE-phoenix-java/ the correct location is http://dev.imjac.in/maven/thirdparty/frc/ctre/Toolsuite-Java/.

I think there's two possible solutions here:

  1. Move all the old versions of the libraries over to the new GitHub-based Maven mirror. It's probably easier for @JacisNonsense to manage just one Maven mirror as opposed to two.
  2. Make it so GradleRIO searches in the correct location for the CTRE libraries in dev.imjac.in.

2016 release

Are you planning to create a release with support for the latest WPI libraries? I see the commit, are you waiting before you create a release?

Unable to deploy

After updating my team's roboRio to the 2017 firmware and updating our router, I tried to deploy and got this error message:

Failed SFTP PUT: C:\Users\Jared\IdeaProjects\SammyRoboRio\build\libs\SammyRoboRio.jar -> Remote21:/home/lvuser

Stacktrace
build.gradle

Official Gradle Plugins Support

Would you be able to put your plugin up on plugins.gradle.org? Instructions on how to do that are here: https://plugins.gradle.org/docs/submit. This makes it much easier to create a robot project with newer versions of Gradle. Instead of

buildscript {
  repositories {
    mavenCentral()
    maven {
        name = "GradleRIO"
        url = "http://dev.imjac.in/maven"
    }
  }
  dependencies {
    classpath group: 'jaci.openrio.gradle', name: 'GradleRIO', version: '+'         //Change this line if you wish to Update GradleRIO
  }
}
apply plugin: 'GradleRIO'

we could simply be able to do:

plugins {
    id: 'jaci.openrio.gradle.GradleRIO' version '# here'
}

GradleRIO and third-party libraries

Starting with the 2017 update to WPILib, classes such as CANTalon are no longer provided as a part of the library. In addition, the only way I've found to restore functionality such as CANTalon usage is to install a CTR library via a EXE installer. I am reasonably confident that this method is not directly compatible with GradleRIO.

How could I use these third-party libraries with GradleRIO?

Clarify Telemetry

It would probably be best before kickoff if it was made clear (perhaps in README.md) what the telemetry captures, and how it is used. (Eg a privacy policy)

Build Failing when attempting to build idea on linux

I don't know if its just because I'm using Ubuntu or not but when i ran ./gradlew idea it output this Downloading https://services.gradle.org/distributions/gradle-3.2.1-bin.zip and after many a dots it finally said

Unzipping /home/user/.gradle/wrapper/dists/gradle-3.2.1-bin/erlz51pt56t1o6vc7t39cikug/gradle-3.2.1-bin.zip to /home/user/.gradle/wrapper/dists/gradle-3.2.1-bin/erlz51pt56t1o6vc7t39cikug
Set executable permissions for: /home/user/.gradle/wrapper/dists/gradle-3.2.1-bin/erlz51pt56t1o6vc7t39cikug/gradle-3.2.1/bin/gradle

FAILURE: Build failed with an exception.

* What went wrong:
java.lang.ExceptionInInitializerError (no error message)

When ran with ./gradlew idea --stacktrace i get

java.lang.ExceptionInInitializerError
        at org.gradle.initialization.DefaultClassLoaderRegistry.restrictTo(DefaultClassLoaderRegistry.java:40)
        at org.gradle.initialization.DefaultClassLoaderRegistry.restrictToGradleApi(DefaultClassLoaderRegistry.java:36)
        at org.gradle.initialization.DefaultClassLoaderRegistry.<init>(DefaultClassLoaderRegistry.java:30)
        at org.gradle.internal.service.scopes.GlobalScopeServices.createClassLoaderRegistry(GlobalScopeServices.java:215)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:538)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
        at org.gradle.internal.service.DefaultServiceRegistry.invoke(DefaultServiceRegistry.java:462)
        at org.gradle.internal.service.DefaultServiceRegistry.access$1200(DefaultServiceRegistry.java:84)
        at org.gradle.internal.service.DefaultServiceRegistry$FactoryMethodService.invokeMethod(DefaultServiceRegistry.java:796)
        at org.gradle.internal.service.DefaultServiceRegistry$FactoryService.create(DefaultServiceRegistry.java:752)
        at org.gradle.internal.service.DefaultServiceRegistry$ManagedObjectProvider.getInstance(DefaultServiceRegistry.java:589)
        at org.gradle.internal.service.DefaultServiceRegistry$SingletonService.get(DefaultServiceRegistry.java:634)
        at org.gradle.internal.service.DefaultServiceRegistry.applyConfigureMethod(DefaultServiceRegistry.java:253)
        at org.gradle.internal.service.DefaultServiceRegistry.findProviderMethods(DefaultServiceRegistry.java:214)
        at org.gradle.internal.service.DefaultServiceRegistry.addProvider(DefaultServiceRegistry.java:352)
        at org.gradle.internal.service.ServiceRegistryBuilder.build(ServiceRegistryBuilder.java:52)
        at org.gradle.launcher.cli.BuildActionsFactory.createGlobalClientServices(BuildActionsFactory.java:148)
        at org.gradle.launcher.cli.BuildActionsFactory.runBuildWithDaemon(BuildActionsFactory.java:108)
        at org.gradle.launcher.cli.BuildActionsFactory.createAction(BuildActionsFactory.java:83)
        at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.createAction(CommandLineActionFactory.java:249)
        at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:239)
        at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:217)
        at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:33)
        at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24)
        at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
        at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
        at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:210)
        at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:174)
        at org.gradle.launcher.Main.doAction(Main.java:33)
        at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:538)
        at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:60)
        at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:37)
        at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:538)
        at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:30)
        at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:127)
        at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:56)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected java.lang.Package[] java.lang.ClassLoader.getPackages() accessible: module java.base does not "opens java.lang" to unnamed module @46271dd6
        at java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:427)
        at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:201)
        at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:192)
        at java.base/java.lang.reflect.Method.setAccessible(Method.java:186)
        at org.gradle.internal.reflect.JavaMethod.<init>(JavaMethod.java:42)
        at org.gradle.internal.reflect.JavaMethod.<init>(JavaMethod.java:32)
        at org.gradle.internal.reflect.JavaMethod.<init>(JavaMethod.java:36)
        at org.gradle.internal.reflect.JavaReflectionUtil.method(JavaReflectionUtil.java:223)
        at org.gradle.internal.classloader.FilteringClassLoader.<clinit>(FilteringClassLoader.java:48)
        ... 47 more

During configuration phase, gradle fails due to missing WPILIB dependency

Per the READEME, I downlaod version 3.0 of the zip file and set up a new project with the robot source. I updated the build file to use our team number and ran the gradlew tasks and got the following errors:

image

At this point Gradle is trying to set up the configuration and has not actually started he build. Any suggestions on how to resolve this issue?

Deploy fails with no internet connection?

When I have no internet at a competition, and I need to make a small change, will I still be able to deploy? I have watched gradlew build fail more than once with no internet, but once I connect and run the same command, it works fine. I can then disconnect again, and builds seem to work for a little while, then fail again. I'm not sure what exactly is going on here, but it seems like maybe the gradle cache is expiring or something. I can still browse to .gradle\caches\modules-2\files-2.1, and all the libs seem to be present when a build fails.

GradleRIO pulls in incorrect version of Shuffleboard

I was having an issue with Shuffleboard and it turns out GradleRIO 2018.01.06 is pulling in Shuffleboard 0.3.0 instead of the proper 1.0.0, even when I change the shuffleboardVersion property in the wpi block to 1.0.0?

Add javadoc for Talon SRX library

There is a javadoc provided in the Talon library zip, could we could include that so it is available from gradle?

Also, it may be better to call it something like CTRLib, instead of talonSRX in the gradle file since it is actually more general than just the Talon SRX.

Could not expand CTRE toolsuite .zip

When trying to deploy the code to the RIO using GradleRIO, the build script fails with a Could not expand ZIP error from the CTRE toolsuite cache.

I found the zip in Windows Explorer and tried to extract it manually, but Windows gave me an error that said the zip is empty. When trying to open the file, Windows claimed that the zip was invalid.

I uploaded a debug log here.

Default RoboRIO addresses have changed in 2017

I've found that the default addresses have changed since 2016 and that they need to be manually overridden in order to work. Without one of these changes, deploy would always fail.

roboRIO-####-FRC.local -> roboRIO-####-FRC.frc-robot.local
10.##.##.2 -> 10.##.##.46

This is after testing with one newly imaged 2017 RoboRIO and GradleRIO 2017.1.0.

Trouble unzipping Toolsuite-Java-4.4.1.14.jar

I am having some trouble with running this in

$ ./gradlew build
:compileJava
error: error reading /home/bloodred/.gradle/caches/modules-2/files-2.1/thirdparty.frc.ctre/Toolsuite-Java/4.4.1.14/94160dbe0ab528f71d83ae75c900f1190984377f/Toolsuite-Java-4.4.1.14.jar; error in opening zip file
error: error reading /home/bloodred/.gradle/caches/modules-2/files-2.1/thirdparty.frc.kauai/Navx-Java/3.0.331/94160dbe0ab528f71d83ae75c900f1190984377f/Navx-Java-3.0.331.jar; error in opening zip file
error: error reading /home/bloodred/.gradle/caches/modules-2/files-2.1/thirdparty.frc.ctre/Toolsuite-Java/4.4.1.14/94160dbe0ab528f71d83ae75c900f1190984377f/Toolsuite-Java-4.4.1.14.jar; error in opening zip file
error: error reading /home/bloodred/.gradle/caches/modules-2/files-2.1/thirdparty.frc.kauai/Navx-Java/3.0.331/94160dbe0ab528f71d83ae75c900f1190984377f/Navx-Java-3.0.331.jar; error in opening zip file
:processResources UP-TO-DATE
:classes
:jar FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':jar'.
> Could not expand ZIP '/home/bloodred/.gradle/caches/modules-2/files-2.1/thirdparty.frc.ctre/Toolsuite-Java/4.4.1.14/94160dbe0ab528f71d83ae75c900f1190984377f/Toolsuite-Java-4.4.1.14.jar'.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 1.715 secs

I tried cleaning and removing the files so it would download again, and it happened again. I tried unzipping the file from the CLI and I got this error:

~/code/robotics/rioTest$ unzip /home/bloodred/.gradle/caches/modules-2/files-2.1/thirdparty.frc.ctre/Toolsuite-Java/4.4.1.14/94160dbe0ab528f71d83ae75c900f1190984377f/Toolsuite-Java-4.4.1.14.jar
Archive:  /home/bloodred/.gradle/caches/modules-2/files-2.1/thirdparty.frc.ctre/Toolsuite-Java/4.4.1.14/94160dbe0ab528f71d83ae75c900f1190984377f/Toolsuite-Java-4.4.1.14.jar
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of /home/bloodred/.gradle/caches/modules-2/files-2.1/thirdparty.frc.ctre/Toolsuite-Java/4.4.1.14/94160dbe0ab528f71d83ae75c900f1190984377f/Toolsuite-Java-4.4.1.14.jar or
        /home/bloodred/.gradle/caches/modules-2/files-2.1/thirdparty.frc.ctre/Toolsuite-Java/4.4.1.14/94160dbe0ab528f71d83ae75c900f1190984377f/Toolsuite-Java-4.4.1.14.jar.zip, and cannot find /home/bloodred/.gradle/caches/modules-2/files-2.1/thirdparty.frc.ctre/Toolsuite-Java/4.4.1.14/94160dbe0ab528f71d83ae75c900f1190984377f/Toolsuite-Java-4.4.1.14.jar.ZIP, period.

Not sure what to try now. They may have gotten corrupted or something. I am also running this on Linux, which may be part of it.

What would I have to do to deploy for JetsonTX1?

I'm relatively new to gradle. James, the creator of the tutorial for using GradleRIO directed me here. From what I can tell (if I didn't overlook anything of course), the default build file will not deploy to JetsonTX1/2 correct? What changes would I have to make if I wanted to do this. It's really tedious to code using geddit on the Jetson and I would much prefer to use an IDE and then just cross compile.

This is for vision code so naturally I'd also need to include the opencv libraries.

If you could just walk me through it, that'd be great. Thank you.

"Examples" link in README.md is broken

In the README, under Features>Dependency Management, there is a link to examples leading to the URL https://github.com/Open-RIO/GradleRIO/blob/master/examples which results in a 404.

Merge build.gradle manifest details into core plugin

Instead of requiring the superfluous "manifest" structure in the users' build.gradle, we could move this into the plugin itself, with a configuration option to not use it.

Furthermore, add to the readme a "baseline" example without jumping straight into the full impl spec (i.e. show the minimum needed to get running)

Code not deploying properly?

I took a look at #1 already, that didn't fix my issue.

When I run gradlew deploy, the "Robot Code" area in driver station still remains red, although Communications are still green, and I can connect to my RoboRIO using http://roborio-2239-frc.local

As shown here, gradle says that it deployed successfully. If there is anything that I'm missing, let me know for sure
image

resolveNativeDeps tries to download nonexistent file

Our code just started failing build (I first noticed it last night) because resolveNativeDeps attempts to get opencv-jni-linux-arm.jar from http://first.wpi.edu/FRC/roborio/maven/release/org/opencv/opencv-jni/3.2.0/opencv-jni-3.2.0-linux-arm.jar, which 404s. I'm pretty sure this is just WPI deleting a file and isn't an issue on your end, but if WPI deleted that file intentionally, the dependency needs to be changed. I'm using version 2017.1.5.

GradleRIO not deploying to robot

For some reason GradleRIO is no longer deploying code to our robot. Our code deploys fine when copied to a fresh Eclipse/WPI project, but all deploys with GradleRIO result in the driver station displaying "No Robot Code".

I previously updated the libraries with an online build, but that did not rectify the issue.

Gradle log:

7:57:48 PM: Executing external tasks 'build deploy --offline'...
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:assemble UP-TO-DATE
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:resolveNativeDeps
:build
:determine_rio_address
============ FINDING ROBORIO ============
-> mDNS (roborio-980-frc.frc-robot.local)...
Host key checking is off. It may be vulnerable to man-in-the-middle attacks.
--> SUCCESS
============ ROBORIO FOUND ============
:deploy
Host key checking is off. It may be vulnerable to man-in-the-middle attacks.
Host key checking is off. It may be vulnerable to man-in-the-middle attacks.
Remote2#75|ldconfig: libraries libfrccanfirmwareupdate.so and libfrccanfirmwareupdate.so.orig in directory /usr/local/frc/lib have same soname but different type.
Remote2#75|ldconfig: /usr/local/frc/lib/libfrccanfirmwareupdate.so is not a symbolic link
Remote2#75|

BUILD SUCCESSFUL

Total time: 32.383 secs
7:58:21 PM: External tasks execution finished 'build deploy --offline'.

I don't think the library error above is the problem as it also showed up in the Eclipse log.

build.gradle:

plugins {
    id "java"
    id "eclipse"
    id "idea"
    id "jaci.openrio.gradle.GradleRIO" version "2017.2.3"
}

frc {
    team = "980"
    robotClass = "com.team980.robot2017.Robot"

    rioHost = "roborio-980-frc.frc-robot.local"
    rioIP = "10.9.80.2"
}

wpi {
    wpilibVersion = "2017.3.1" //Provided by Eclipse
    talonSrxVersion = "4.4.1.14" //Provided by CTRE Toolsuite
}

dependencies {
    compile wpilib()
    compile talonSrx()

}

def robotManifest = {
  attributes 'Main-Class': 'edu.wpi.first.wpilibj.RobotBase'
  attributes 'Robot-Class': frc.robotClass
}

jar {
    from configurations.compile.collect { it.isDirectory() ? it : zipTree(it) }
    manifest robotManifest
}

task wrapper(type: Wrapper) {
    gradleVersion = '3.2.1'
}

Version 2017.1.1 of jaci.openrio.gradle.GradleRIO Doesn't Have "toastDeploy" Task

On Mac El Capitan, when I run "gradlew tasks", there is no "toastDeploy" task listed. Not sure if this is a mistake or the method to deploy toast to roborio has changed.

build.gradle file looks like:

plugins {
id "java"
id "eclipse"
id "idea"
id "jaci.openrio.gradle.GradleRIO" version "2017.1.1"
}

repositories {
mavenCentral()
}

frc {
team = "4330"
robotClass = "frc.team4330.screambunction.RobotModule"
}

dependencies {
compile fileTree(dir: "libs", include: "*.jar")
compile group: 'jaci.openrio.toast', name: 'Toast', version: '+'
testCompile 'junit:junit:4.12'
}

def robotManifest = {
attributes 'Main-Class': 'edu.wpi.first.wpilibj.RobotBase'
attributes 'Robot-Class': frc.robotClass
}

jar {
from (zipTree('libs/navx_frc.jar')) {
include '**/*.class'
}
manifest robotManifest
}

task wrapper(type: Wrapper) {
gradleVersion = '3.2.1'
}

Long Deploy Times

We've been experiencing excruciatingly long deploy times using GradleRio this whole season (sometimes 40+ seconds, usually around 30). This has been happening on multiple laptops and multiple roborios, so I don't think the problem resides there (but it might). It is also happening with offline deploys, so it isn't a network speed problem. I'll have a whole log for you tonight (~ 2 hours from now), but in the meantime, I have two questions:

  1. Is this normal? I thought I remember reading somewhere that deploys were supposed to be ~15 seconds.
  2. Is there anything we can do to shave time off?

Our build.gradle is embedded below.

plugins {
    id "java"
    id "eclipse"
    id "idea"
    id "jaci.openrio.gradle.GradleRIO" version "2017.1.2"
}

frc {
    team = "3322"
    robotClass = "org.usfirst.frc.team3322.Robot"
    rioIP = "10.33.22.2"
}

dependencies {
    compile wpilib()
    compile talonSrx()
    compile files('lib/navx_frc.jar')
}

def robotManifest = {
  attributes 'Main-Class': 'edu.wpi.first.wpilibj.RobotBase'
  attributes 'Robot-Class': frc.robotClass
}

jar {
    from configurations.compile.collect { it.isDirectory() ? it : zipTree(it) }
    manifest robotManifest
}

task wrapper(type: Wrapper) {
    gradleVersion = '3.2.1'
}

RIOLog Plugin Not Found?

Hi,

We're very excited about this project on team 3932, great work! We have a windows install where the plugin for the riolog isn't present in eclipse and there doesn't seem to be a way to view the rio system out log.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.