non-interfering module model #41
Conversation
Signed-off-by: Noam Dori <TheNODO55@gmail.com>
This fix solves issues where data saved on the module is removed like (#39). Signed-off-by: Noam Dori <TheNODO55@gmail.com>
Signed-off-by: Noam Dori <TheNODO55@gmail.com>
|
I tested this PR in CLion/Linux. It doesn't seem to help with the problem described in #39. Steps I did:
I have a single project open when opening/closing CLion. Hatchery is disabled. How can I help debugging this issue? |
|
From what I understand, the issue comes from the module system. Thus, any info you have on the modules is useful for debugging. Also, since this fix changed the module/library model, projects from version 0.1.5 might have a harder time with the update. Did you use a new project or an old project that used 0.1.5 before? |
|
Now I'm confused. I succeeded building the plugin using gradle now. I still get the ambiguous Module errors. I had to substitute all instances of However, if I install the plugin built by me, it doesn't seem to work. .msg file coloring and go to definition work, but package.xml completion shows nothing. Also, the project root project view doesn't have the "dot" marking a module. If I install the version you provided (overwriting the custom-built version), I get startup error
modules.xml: robot_self_filter.iml: workspace.iml: I'll try with a clean project. |
|
This happens because this fix creates a new module type, "WORKSPACE_MODULE_TYPE". In regards to the issue with your current project, it seems there is a bad library there thats causing trouble, the "workspace" library which workspace.iml depends on for some reason. It is also the reason why the coloring still works. |
|
With regards to building from source, I use Java 8. Java 11 introduced special modules which is probably what causes the ambiguity. I would like to see a screenshot of the project view after you built it, specifically the package folders. Did they become blue with dots? I think I may have distributed the wrong version in the zip because the fix is supposed to recognize the new module type. I updated a the zip with the version I checked against so it should be able to recognize the new module type. |
|
I did tests with clean projects (deleting .idea). And yeah, I also concluded the distributed zip is wrong. Nevertheless, here are my findings (I'll update them with the newly provided zip).
|
The first start after updating the plugin with .idea deleted ended up without ROS in Second start added even the ROS entry to Then I changed plugin settings, removed all "additional workspace paths" and set the "workspace path": The workspace entries are indeed displayed as modules, even
However, package.xml completion in Surprisingly, after a while clicking around, I probably got the plugin working (sorry, no screenshot). It displayed red underline for After I restarted CLion, all of it was lost. Moreover, |
|
First, the issue with the red tags is a bug that was solved in the main branch. This means the plugin fully worked when you got it to that state. Here is a reference of how things are on my tests for reference: |
|
You mean you open the whole workspace as the CLion project? That would work when using the standard catkin, which makes CMakeLists.txt around, but e.g. catkin tools do not make any additional CMakeLists.txt outside the projects. I use this type of build, and thus I can't open the whole workspace as a project. |
|
Anyways, the CMake issue is gone using this branch. But at least a part of the plugin doesn't work, so I can't tell if it's because the bug is fixed or because the plugin doesn't do anything... |
|
I think I managed to replicate your scenario. From what it seems both from the .idea folder and from a functional point is that the only problem with the CMake module is that the project view does not properly show it (which might be because the ROS module ws/catkin_ws is a parent of the CMake directory). Were you unable to use any feature of the plugin or of CLion save for that visual bug? From my tests everything worked including proper file icons, package.xml completion, and general package completion. |
|
As I wrote in my observations above, package.xml completion does not work for me with the updated plugin. Or - it worked once and then "got lost" after a restart. |
|
I replicated your problem. What stood out to me was that in your screenshot, all the other packages were recognized correctly. In my replicated scenario, I opened a new workspace and in it I put two packages, one which I opened as a project and which I didn't. The thing is, I first opened the workspace as a project. Basically you have 3 options to solve the "nesting projects" issue:
Sadly I don't think there is a way to be able to both keep all .idea folders and open a package as a directory because the ROS workspace module requires knowing about the workspace directory's contents. This also explains why this bug only happened when you re-opened CLion since it is caused by loading the wrong .idea folder which only happens when you open a project. In short, you probably have two conflicting .idea folders in your package, Let me know if this solved your issue or if there are still problems |
|
I'm sorry, I don't have any nested .idea folders, yet the problem is still there: |
…when loading the project from a package or from the catkin_ws itself, but fails miserably when loaded from meta-package root or from src... Signed-off-by: Noam Dori <TheNODO55@gmail.com>
this system works on all models with CLion (and other IDEs), save for WSL models where URL loading is broken. Signed-off-by: Noam Dori <TheNODO55@gmail.com>
|
the latest commits to this branch fixed the model. This was tested on:
However, there is a weird bug where if you change a library item, indexing for packages crashes. This will be worked on in the next version since this version waited long enough. The issue ticket for it is #46 |
|
I'm sorry, I tested the 0.1.6b2 release and not much improvement there. I tried even with a completely "clean" package (no .idea folder) in a workspace with other packages, which "depends" on other workspaces (or extends/overlays them, in other terminology). But no recursive .idea folders. All I got were the previously seen errors - cpp files reported as not belonging to the project, ROS and workspace items disappearing from header search paths after reloading CMake project, package.xml all or mostly red. No matter if I restarted CLion in between. In the console, I saw an abundance of exceptions, e.g.: or |
|
Once CLion even disabled the plugin saying that it was unable to save its settings (but I haven't been running that CLion instance from console, so I don't know exactly what went wrong). I also tried running clion with or without the ROS environment sourced, but that didn't change anything. |
This PR makes sure the project model is not destroyed every time the IDE is opened, and that ROS works independently of the IDE functionality.
This is done by creating a new module type for the ROS model, and making sure the core library and the new module are not destroyed every time the project is opened.