I recently started as software mentor for a local team for 2025. I am new to EVERYTHING (FRC, wpilib, pathplanner, VSCode, GIT, etc – my experience is mostly in Java, Eclipse and SVN). I got far enough in VSCode and wpilib to run a Romi robot. However my effectiveness with VSCode and lack of support for software development using projects, much less multiple projects with references, is pretty low.
I tried bring up my Romi project in eclipse. It compiles but it complains about missing native libraries. I tried spoon feeding them to the project dependencies but am still missing a critical one (and this is not a real solution – need to learn more about Maven and Gradle). Even if I could resolve all dependencies I suspect that simply running a java program is insufficient – need to to use the “magic” commands in VSCode like “SimulateRobotCode”. Not being familiar with VSCode I have not been able to discover what this is actually doing so that it can be reproduced in eclipse.
Has anyone brought up wpilib in eclipse? Any idea if this is doable? Is this a fool’s errand?
It it definitely possible to use another IDE than VSCode. At 4481 we use IntelliJ because of personal preference, but running a custom setup creates extra hurdles that you might not want if you are new to everything.
The “magic” commands like SimulateJava are all Gradle tasks that can be run from a terminal in case you opt for using another IDE.
The WPILib documentation is an excellent resource for almost everything, and depending on the topic, it is significantly harder to follow if you are not using the default VSCode setup.
What are the exact issues you face with VSCode that you can eliminate by switching to Eclipse?
I am trying to develop some common utility code that can be used for, say, performing sysid and for operating the robot. In eclipse this would be three projects: one for the utility code, with its unit tests etc.; another for normal operation executable, and a third for running the sysid executable. In eclipse projects and project referencing is a primary use case, in vscode projects don’t even exist.
In googling around and talking to someone that uses vscode it seems the solution is to “copy the redundant code” into each project rather than referencing it. From a software development perspective, this is a big no-no.
Is there some more reasonable way to do project-like development with reusable common code? Can I “checkout” separate projects from GIT into a single vscode project?
BTW: Thanks for revealing the magin. I suspected it was gradle but can’t find the code used for wpilib magic by searching. Do you happen to have the link in their deployed file hierarchy?
I don’t think that’s always the case, especially in FRC where the code base is small and the developers (=students) are not very experienced. Last year we had an external common library but it made more problems than solved so we just reverted to a monorepo.
It is possible to retain a multi project structure by dividing your gradle project into multiple subprojects. These projects can be different git submodules (references to external repositories). But this all gives extra overhead. I think for 95% of the teams, a basic understanding of git and the default VSCode setup is enough.
We use a custom setup with multiple inner projects (2025 robot and generic library), along with a non-standard IDE because I wanted to dive more into DevOps. But we have been training with it since September so most students are used to it and the adoption had been gradual. But I think this is overkill for most teams. Especially if there is no broad experience within the team.
Gradle tasks
Regarding the gradle tasks, the ones that you will probably use most are ./gradlew build to compile your code and optionally run unit tests, and ./gradlew deploy to build and deploy code to your robot. Nearly all other tasks are requirements for deploy and are not used directly. I can still provide a screenshot of all possible tasks if you want tho.
Great information. Much thanks for clarifying and providing perspective. Since everyone on the team, including the software mentor – me – are just learning, KISS seems to be the way to go.