When droppings are installed no check are done regarding the dependencies. So it’s possible that Python4Capella install newer versions of some dependencies that prevent droppings to work. The best way to solve this is to use update sites instead of droppings if possible to install add-ons. This way p2 will make sure all dependencies are present and can be resolved.
This includes using the “Add…” button and installing directly from a folder/or an archive, even if that does not come from an url site?
The requirement addon would not be added using the add folder/archive method, although, some addons cannot be found on the internet and can only be added using folder/archives.
Thanks for the answer by the way.
(subNote, i did not answer you yet in the generation doc subforum, i will later)
Yes use the Help/Install new Software… menu then add a p2 update site either and archive or an URL. You can also try to revert the Python4Capella installation (click already installed in the installation dialog then the installation history tab), then install your new addon then reinstall Python4Capella… not ideal but might work.
The other solution is to use the OSGi console to see why some bundles can’t be started. You will need to install the PDE (Plug-in Development Environment) to have access to the OSGi console.
I thought PDE was already installed, since it is possible to change the viewpoint in Capella into PD:
In any case, i cant see the OSGi thing.
My requirement droping cannot be installed using the update site, the only was I was able to make it work was by drag and drop it in the dropings unfortunately (and restart).
Sorry for asking this but what is “p2’” ?
I am used to install things through the archives or files (Proof: M2DOC).
Ok i went searching for a more complete PDE just in case, and i found these ( Eclipse software repository | The Eclipse Foundation) but the “url” method never work me, as i have a restrcited netrork suspcious of this random downloads, only method is to download an archive/folder and add it manually.
p2 is the Eclipse package (OSGi bundle) management system, some information here. It make sure the installation is consistant and install dependencies if needed.
Yes the installation process is the same as M2Doc or Python4Capella.
The PDE can be installed from the Eclipse update site. You can check the Eclipse update site corresponding to your version of Capella in the M2Doc target platforms. For instance for Capella 1.4.0 it’s https://download.eclipse.org/releases/2019-06.
Ok so for Capella 5.1 which I am using, it is 2020-06 Eclipse software repository | The Eclipse Foundation
However as I mentioned, my restriced network prevent me from using the “url” method of installing new “software/addon” inside Capella/eclipse. At least it seems so.
After pressing enter, and after the error message, it leaves me with nothing:
More importantly for me, I hope have an opinion/idea about this, here is goes:
Are there some parameters to check/configure before packaging an addon, in order to make it possible for it to be installed using the menu > help > install > Add…?
I am asking this because lot of dropins that I am using, or even the one I am making, can only be inserted to cappela through a simple drag and drop to the dropings folder. I mean that, if I try to do a menu > help > install > Add… I would get no option, such like this:
It is the case for the Requirement viewpoint Official Capella Add-n, for instance.
To sum up:
i CANNOT install anything using URLS, because of the restrictions my internet network has.
I can only use the drag and drop method.
If the addon does actually need to be installed using the menu > help > install > Add…(such as M2DOC), then the addon can be put anywhere and installed anyway.
If the addon “would not” display any result with “menu > help > install > Add…”, then it can ONLY be added to my capella if i drag and drop it directly to the dropings folder. Thats the extent of my understanding.
I was wondering if I was missing anything.
And if it was possible to make the addons which cannot be installed with though menu, … well make them installable through the menu >… > add?
If that was ever related to the configuration of the packaging somehow when creating an addon? And if that configuration existed, then IF that configuration was missed before/during packaging, i was wondering if there was any other tweak to do after the packaging to make it "installable through the …add menu)? I would do that to the requirement addon which is already packaged. Among other packages which I would like to apply that.
Hope this is clear. Thanks a lot for every answer, it is really appreciated, that’s the least can be said honestly, thanks.
Hello again Yvan,
This is the most frustrating problem i encountered since a long time.
I took a look at the capella github page talking about Development Environement, it states how to it with a standard eclipse dev platform and speaks about the Eclipse modeling tools.
It also states the debug button (Open perspective…) available in Capella
Anyway I checked the console of Capella and found the “Host OSGi Console” button. Here is what it gives:
Do you think I can already start looking at what is the problem?
(Reminder of the problem: I have a capella model in Capella, few extensions are installed, + P4C and M2DOC, when I delete one of the extensions I made (from the DROPINS folder) and replace it with a new version (same extention name)), it will never appear again in the kitalpha manager. Now if I deleted the new version of my extension and put the older version again in the DROPINGs folder, the extention APPEARS in the kitalpha manager).
One hint for the core of the Problem which can be useful here: it is VERY strange but when i proceeded to delete my extension while Capella was open, it would let me do it. This should not happen, as Capella always prevent the user from touching the dropings when it is open, a pop up window would open saying: you cant delete such droping because it is open by java. That is my experience in the past with Capella at least, to say the least.
I hope I can find what is the problem, so you said I could check in the console somehow? Could you tell me more?
Again, the extension does not show at all in kitalpha manager. (So impossible to reference it etc)
Finally, p2 update stuff is out of the equations as my network blocks all of update installation anyway (Network related restrictions i guess).
There are instances where I did not have this problem even though P4C was installed.
I also noticed this problem whenver a .zip file was present inside the dropings, problem goes away when the .zip is removed from there. Unfortunately I have the problem today even without any .zip file.
I found one solution, interesting.
Importing the workspace to the original capella studio reponsible for the making of the old extension, will allow us to use newer version of the extension if they are compiled/generated in the old Capella Studio. Meaning Capella will reconize the new extension.
Strange but oh well.
Yes you can try to install and start OSGi bundles from the OSGi console. I’m a bit confuse to with the fact that changing the worspace helps… Maybe the problem is not related to OSGi but some preferences stored inside the workspace.
Hello Yvan, Welcome back! You have been missed!
What Was I supposed to write under that host OSGi window I had opened?
Anyway, yes going BACK to the the very first Capella Studio responsible for the workspace that I am navigating from a Capella Studio to Another, makes the workspace works fine again. Meaning => When I compile and package an add-on it works fine.
Whereas, if I am using a workspace (copy paste) from ANOTHER capella studio, sometimes packaging the add-on will produce an add-on that is never recognizable by Capella.
To sum this up:
Let’s say we have 3 elements:
Capella Studio 1
Capella Studio 2
– Making a workspace in CS1 → packaging an add-on → testing it in Capella (OK)
– Then, copy paste the workspace from CS1 → Paste it in CS2 → Open it with CS2, everything is there, the odesign/ecore etc… you modify the elements as you wish. BUT when trying to → Package a new add-on → Use it in Capella? → Capella DOES NOT SEE the new Add-On.
– Now, if you copy the workspace from CS2, and paste it again in CS1, then → Package the add-on → put it in Capella → Capella reconize it again!
You use two different copies on the disk ? Because one explanation could be one of the CS building while the other one is packaging.
I don’t know what could produce this behavior. Maybe some preferences in the workspace used by Capella/Capella Studio ? Maybe you can try to ask this question in the main Capella forum ?
I use about 10- Capella Studio’s in one disk (disk1)…
I have other set of 10-15 Capella Studios are in another disk (disk2).
Let us summerize what is happening to try to find a solution.
Right now I have a workspace with an odesign file that manages an extension of “Property view description” type.
This workspase + all the files of the project were made in disk 2 ORIGINALLY ( I THINK?).
When I copy paste the workspace from disk 2 to one of the Capella studio of disk1, the workspace is properly reconized by “Capella Studio” (Of course I delete “MDEReport” and “.metadata” + anything not directly related to the “contents” of the extension). After I delete those items I can open the rest of the files (.design, . vpdsl… all of them) I mean i open the “folder” containing them and Capella Studio reconize them.
From here I can open the odesign and “work” I can modify the contents of the aql fields etc… No problem until here.
When I try to PACKAGE the extension. The packaging happens normally, BUT as soon I copy paste the result (the resulting addon) into the dropings folder of a Capella installation… Capella does not reconize this new extension (It does not appear at all in the kitalpha manager)
Must I remind you this particular Capella contain Python 4 Calella, EEF and updated version of sirius.
All of this happened in disk1 because I copied the project from disk 2 to disk 1.
NOW, if went BACK to disk2 (where the project has been made originally i think?) and I modify the contents of my aql fiels etc, THEN package the new extension → The new addon added into the dropings of the Capella installation works fine. Capella Reconize the new extension (It appears in the kitalpha manager).
Third experiement, i use the same extension from disk 1, the one that was NOT working. And I add it the dropings of a NEW CAPELLA INSTALLATION (a very fresh one), —> Kitalpha manager reconize the new extension eventhough it was not pakacged in a Capella studio of disk 2.
The fact it works in a new Capella, makes me think that installing Python 4 Capella… somehow “locks” the dropings folder? And make it not possible to add “new extensions” that were installed in “different” capela studios? (Capella reconize new addons as long as they are installed in old Capella studio that originated the first addon (disk2) I hope this is clear)
Maybe installing Python4Capella updates one dependency of your add-on and after that it can’t be loaded… the droppings mechanism was been deprecated 10 years ago if not more. P2 make sure this kind of issue doesn’t happen and explain why an installation can’t be performed.
Did you try to start the OSGi bundle of your add-on from the OSGi console and see if some dependency was missing ?
The problem with Update Site (P2 Right?), is that I am using a “protected” network, I cannot install ANY extension through the update site method. I can only drag and drop extensions inside the dropings folder.
To be honest, I am still not sure how to do that? I was able to open what seems to be an already integrated OSGi console (one of my previous screenshot/posts), it was available in the console tab you just need to select it. Don’t know how to check the dependencies from there, what to write what to do etc…
You can try the command ss to see if your bundle is installed. If its not it’s not a good news I guess, but you can try to install it using install file://... then you can try to start it start 1234 with the ID returned by ss or install. At this point you should see if there is an issue starting the bundle that might help figuring out what is going wrong.
Ok very interesting!
So I checked the installed bundles when I have the right extension (the one produced in disk 2 = the one that kitalpha manager can “see”) and compared with the list of installed bundles when i have the wrong extension (the one installed in disk1). I noticed that the bundles from 1135 to 1145 were missing:
These lines do not appear when I remove the working extension from dropins and add the one that kitalpha manager does not “see”. It means my bundles stop at 1104.
So I went ahead and tried to instal the missing bundle.
It’s kinda like a command windows it seems, I wrote “cd dropins” to move the right folder.
Now I tried these for installation but none worked, maybe I am doing something wrong: