Changed folder capitalization, now get runtime errors

I added a folder IO and some java stuff. Got it working. Realized standard is folders are lowercase. SOOOooo, I renamed the folder and all package references. Deployed worked but when I ran it it through a runtime error, unable to locate xxx.java that was in the renamed folder.

Renamed the folder back to IO, Deployed and all is good, again.

Any thoughts?

Thanks

Are you on windows? If so, you’ll need to rename it something else, and then change the folder back to lowercase. Just changing casing doesn’t affect windows, and it will still be capitalized.

Yes I’m on Win 10 and Nope it didn’t work.

Rename from IO to myio then deployed, OK.
Rename from myio to io then deployed, nope. Didn’t Save All before deploy, maybe(?).
Rename back to myio, Save All & Deploy, OK.
Renamed to io again, Save All & Deploy, nope.

My guess is there’s a hidden file somewhere, windows or roboRIO, that isn’t releasing IO.

I’ll keep peeking & poking around. At this point I could have rewritten the whole thing. Now it’s a challenge! :slight_smile:

Thanks

OK, not sure when the train runs but I see light at the end of the tunnel.

I made a copy of the project folder, MyBot_JCH in Windows and renamed it to MyBot_JCH2. Opened the new folder and deployed. It worked. Hmmm?

Went back to MyBot_JCH & deployed. Still not working. HMMMmmmm?

Temporarily opened MyBot_JCH2. Renamed MyBot_JCH to MyBot_JCH1. Opened MyBot_JCH1 and deployed. It worked! The same project renamed now works. HHHHMMMMmmmmmmm?

One more try. Temporarily opened #2. Renamed #1 back to the ORIGINAL MyBot_JCH, deployed. Wait for it … wait for it … IT WORKED! I now have the original name project with the correct capitalization but will now deploy and work.

Still have NO idea what the cause is but I now have a work around. May not have vanquished the dragon but wasn’t defeated. Call it a draw. Next time!

Thanks.

Can you share the code and/or stack trace?

My guess is that you didn’t run a gradlew clean deploy and that was somehow different than a gradlew deploy.

But if it works now then that’s great! Also, if you want us to actually help you solve the issue (if this pops up again), show us the entire stack trace of the runtime error.

1 Like

I created another project and was able to repeat the issue. I would try a gradlew clean deploy if I could figure it out. :slight_smile:

I’d post by code on github but still figuring out how to create a repo on git to push to from VSC. :slight_smile:

Thanks.

So a gradlew clean deploy can be run using

Windows:

gradlew.bat clean deploy

Linux/Mac OS:

./gradlew clean deploy

This is of course using the command line. Normally you shouldn’t have to do this and to be honest, it was just a guess that doing that compared to a normal deploy would somehow affect it differently, so it may not change anything.

You don’t have to post your code on github yet, but if we’re unable to fully understand the stacktrace that you give us, we may also need the code to help you out.

That did it. I created a new project, added a IO folder and some code. D/L’ed and it worked. Renamed the folder to io and corrected the references and D/L’ed. From driver station clicked Enable and within 3 seconds got the error message. Ran gradlew.bat clean deploy and it now works. I’ll have to add that to the toolbox.

Ahhh? stacktrace? If you still need it, I’ll need some more info.

Thanks,

Stacktrace is a fancy term for the entire error. Here’s a link that gives examples of stacktraces: https://stackoverflow.com/a/3988794/5434860

Sometimes the error message that <insert tool here (ex: gradle, VS Code, etc)> gives you doesn’t look like that. Sometimes the stacktrace is hidden when using certain tools. If it is, don’t worry about it, give us as much as the error as we can and if we need more, we might have you run another command to give us the full stacktrace.