Provide and document a workaround that allows VSCode to resolve WPIWebSocket symbols when working on Java files in plugin/controller.

[brettle]

No description provided.

[CoolSpy3]

For reference, I haven't run into this problem on Windows WPILib VSCode 2024 (Java Red Hat v1.26.2023121408 Pre-Release). I do sometimes have the problem of not resolving those symbols, but VSCode finds them after I build the project.

That being said, I'm willing to move forward with this if it fixes the problem on other systems. My one concern with these changes is that if we add mavenLocal as a dependency, DeepBlueSim could build off of the WPIWebSockets there rather than the submodule (because publishToMavenLocal is not run automatically on build). Thus, we could get a case where someone updates the submodule, but those changes are not reflected in the built controller. Is that something we should worry about, or will gradle always build against the subproject?

Alternatively, would it be enough to change line 70 of controller/build.gradle to implementation project(':WPIWebSockets')? (which also might better reflect its intention)

[brettle]

For reference, I haven't run into this problem on Windows WPILib VSCode 2024 (Java Red Hat v1.26.2023121408 Pre-Release). I do sometimes have the problem of not resolving those symbols, but VSCode finds them after I build the project.

I suspect the problem might be associated with the latest stable version of the Java Language Support for Java by Red Hat (v1.30.0).

My one concern with these changes is that if we add mavenLocal as a dependency, DeepBlueSim could build off of the WPIWebSockets there rather than the submodule (because publishToMavenLocal is not run automatically on build). Thus, we could get a case where someone updates the submodule, but those changes are not reflected in the built controller. Is that something we should worry about, or will gradle always build against the subproject?

Gradle will always build against the subproject. The documentation says "Gradle will inspect the group and name for the projects in the included build and substitute project dependencies for any external dependency matching ${project.group}:${project.name}." I have also confirmed this by publishing a broken WPIWebSockets, then fixing WPIWebSockets (but not publishing), and confirming that ./gradlew build works.

Alternatively, would it be enough to change line 70 of controller/build.gradle to implementation project(':WPIWebSockets')? (which also might better reflect its intention)

Tried that before pursuing the current route and it didn't work. It also has the minor disadvantage of preventing the plugin project from building on it's own using a published WPIWebSockets, if we ever want to do that.

If that makes sense, please merge. If not, I'm happy to discuss further.

[CoolSpy3]

That addresses all of my concerns!