Made a hacky fix using rosdep db to resolve rosdep keys (#47)

[Doomerdinger]

Parses the console output of the command rosdep db to aquire addition rosdep keys that may not be caught by the existing method.

Probably should add more features (ability to toggle this on or off, ability to toggle using this in place of existing method, resorting to that one if this fails or vice versa, (?) bubble explaining this option) but I haven't work in java in years. This fixes my immediate issue, use it if you'd like.

[Noam-Dori]

First, any contribution to the plugin is welcomed

Second, good to know rosdep db exists. However, it has problems when we try to run it on windows. This limits ROS2 (and to some degree ROS1) compatibility. The method I use skips over the command and fetches the dependencies directly from the URLs. It is also possible to do the same with the rest of the packages (albeit with a little modification) using the very link you sent on your issue (#47). In fact, all ROS1/2 distros put their package lists in that repository. A potential, platform independent solution could parse the list and get all the packages from there.

However, even when we use rosdep keys for actual ROS packages, we lose important info on the way:

• Is the package installed on my computer? The actual package list is very big, and there is the strong possiblity that we forgot to install a package
• Even if the package is already installed, we can't learn anything about it since the name is tied to a rosdep key and not an actual ROS package. We lose out info about new message types, the dependencies of those packages, etc.

For this we need to link those real ROS packages to a complete ROS package type. In our case, this is ROSCompiledPackage. The plugin actually tries to find those ROS packages in the ROS library it loads. However, there is a fundamental bug that either causes the library not to be registered with the system (this line fails) or that the files in the library fail indexing completely (We can see the error when we try to use the scope the finder defines). the next step would be to ask JetBrains about this issue since I did follow their library guide to no avail.

This is what I know about this bug and what could cause it.

[Doomerdinger]

I didn't intend for this to be a final fix by any means, just figured I throw a PR out there in case this was "good enough" at the moment. Feel free to close the PR.

It would appear that the parsing you use just doesn't work with the way the new yaml files are structured (the existing parsing assumes every package is on the base level of the yaml, where the new one all the packages are not - and then some metapackages do things a bit different than all the other "normal" packages).

I was going to fix the parsing to support both formats (as well as the index yaml and subsequent lookup), but that would've taken a bit longer and I don't have the time at this very moment. I may go and address it over the weekend.

I'll likely be contributing to this project in the future, since it seems to be the only actively maintained functional ros plugin for clion, just FYI. Do you happen to have any way of testing the functionality of this plugin without building, installing it in clion, and reloading? Like I said before, haven't worked with java in years - and never on a jetbrains plugin - but I didn't see much in the way of testing, automated or manual.

[Noam-Dori]

You can manually open any IDE instance directly from the plugin by either running gradlew runIde, or choosing runIde from the run options which should be available if you are using IntelliJ IDEA. Let me know the runIde task doesn't exist in the IDE.

More details are available in this wiki page but I don't have specific instructions on testing the plugin (yet).

[Noam-Dori]

This issue seems to be solved with the latest commits, if it does happen, open a new issue