I don’t have access to the final product Melody and your request go further simple support on M2Doc. We can probably help you with commercial support, @SamuelRochet will contact you.
I tested M2Doc 3.1.1 with Capella 1.4.2 and it works, the service fromHTMLBodyString() is found. But in this configuration the M2Doc Capella extensions can’t be installed so I had to remove specific services from the IFE example (replaceLink(), getCeDirection(), getDestinationComponent()), the service import in the template and also change the version of M2Doc to 3.1.1 in the template.
Hi Yvan,
currently we again have this very same issue in the same combination of m2doc and Capella (3.1.1 + 1.4.2) versions occuring across templates and users - '<—Couldn’t find the ‘fromHTMLBodyString(EClassifier=EString)’. Now, it is good to know it works at your premises. So we simply have to identify the issue which causes the problem at ours. Could you pls expand a little bit on what you mean by ‘had to remove … the service import in the template’?
Or may be you have also another idea where we need to look? (We had to change the default workspace of Capella, which also changed its configuration directory - may be this is related to the issue, because it stopped to work afterwards). br, M.
… it cannot be stressed enough that it would be nice to have a response, as we are currently blocked and I am hopeful we could find the reason why and resolve this, actually.
You need to make sure you have the feature “M2Doc HTML Integration (experimental)” org.obeonetwork.m2doc.html.feature is installed in your Capella. And you don’t need to import any service class by hand for this service to work.
Yes, I know, that is how it should be, but as I have written yesterday here Postprocessing of M2Doc Documents by Visual Basic we have this feature installed, it is visible in the installed sw dialog. … Or should we may be reinstall this feature? How - via an update site?
@YvanLussaud, @UweW, @plm Hi Yvan, we experience now exactly the same issue “Invalid query statement: Couldn’t find the ‘fromHTMLBodyString(EClassifier=EString)’ service” in Capella 5.1 + m2Doc 3.2.0. The “M2Doc HTML Integration (experimental)” is installed acc. the list of Installated Software in the Installation List. Is there any new relevant information or anything else we could try out wrt this issue since the last time? br, M.
There is nothing new, this service is tester on each version of Capella when the M2Doc extensions update site is built. We also tests the installation and the generation with Capella Team. So I’m still not sure why it doesn’t work for you out of the box.
There is a new version of M2Doc (it will be the 3.2.1 after the release) that improve the conversion form HTML+CSS to docx. But the packaging is still the same so I’m not sure it will help you. The nightly build can be found here:
This version is not a release but should be close to the released version. Let me know if it helps.
After updating/installing M2Doc your qualifier should be 3.2.1.202112101442 and not 3.2.0.
There is also a zipped version of the update site here if needed:
Yes, I´ve meant we have not done the upgrade to 3.2.1 ye, so it looks like in the above screenshot. So it is ok and it should work with 3.2.0 also, that is what you mean. But we will try 3.2.1 as well.
From the other thread you should also check the org.jsoup plugin. But for M2Doc everything seems fine.
Hi,
I have tried several ways installing M2Doc. I have used the version 3.2.0 and 3.2.1 . Both versions I have installed with different methods: the standard update-site zip and installation as dropin.
The behaviour is always the same.
In some cases ‘fromHTMLBodyString()’ works. But, it all seems to depend on if the jsoup plugin is getting loaded or not. I could no sort out why sometime jsoup is loaded and sometimes not.
I remember with Melody 4.5.2 the issue was also that jsoup did not get properly loaded. The recommendation from the Thales support then was to install m2doc as dropin, which helped at that time.
This time it does not help.
Shouldn’t jsoup be explicitly required and loaded by m2doc? As a user I should not need to check for it.
Jsoup is required by M2Doc see this manifest and also this feature.
I don’t know why it can’t be loaded in your configuration. If you install everything using p2 (update site) you should have errors on what is incompatible.
Do you have other versions of the org.jsoup plugin in your installation ? Maybe I can open the range for jsoup if it don’t break the code.
In fact, I am not so much in the details how it works internally with eclipse/Capella.
What I can say: I have installed many add-ons on top of Capella, M2Doc is just one of them. All the add-ons have been installed with update-site mechanism (no dropin installation). All add-ons have been installed as shared installation in admin mode (with admin.bat).
If I run Capella as admin with admin.bat, jsoup is loaded:
org.jsoup (1.8.3.v20181012-1713) “jsoup” [Resolved]
If I run Capella as normal user, jsoup is not loaded.
So, it seems there are conditions under which jsoup is loaded and conditions under which it is not loaded.
Some bundles can ask to be unpacked, maybe only the admin can do that or the jsoup jar file is not readable by normal users ? or the unpackage verison is only readable by admin ?
Well, I have no idea …
But, from my point of view it has been installed just as any other bundle. And from access rights it is readable by all users.
I do not know how the loading of modules internally is done. I just see the result.
As admin:
As normal user:
I just had a joint session with the TCE support (Philippe DUL) and we found, I would say, a workaround.
I uninstalled M2Doc and jsoup from the shared installation as admin. Jsoup could not be completely uninstalled, because it is used by some other feature. But, it was removed from the ‘Installed Software’ list. It still is available in the ‘Plug-ins’ list.
Then, I installed again M2Doc. Jsoup is not added again to the ‘Installed Software’ list.
Then the ‘fromHTMLBodyString’ issue disappears and it works from admin mode and normal user mode.
It seems that jsoup should not be checked if you do the initial installation of M2Doc?! (I do not get all the dependencies). At least it works now.
Hi,
It seems there might some differences between your two launch contexts but also around plugin installation, dependencies resolution or dropins detection when multi-user configuration is used.
I do not know which kind of property/config is used on your side in you .bat scripts, but I already had to use the following process to have a working workbench after some manual updates.
In my use case, the multi-user configuration was set with the use of the following properties in configuration/config.ini:
osgi.instance.area.default=@user.home/Capella_XXX/workspace
osgi.instance.area=@user.home/Capella_XXX/workspace
osgi.configuration.area=@user.home/Capella_XXX/configuration
The steps were the following:
- comment those lines and save
- launch Capella in a single user context and a temporary workspace (./wkp for example)
- check installation details, plugins start, … jsoup detection or even M2Doc behavior
- stop capella
- uncomment the multi-user configuration
- launch capella as before and check the jsoup detection, start and M2Doc behavior
In your case, I would try this with adaptation of steps 1. and 5. to disable and then re-enable the multi-user config.
It seems from your attempt with Philippe that you have switched from admin mode to user mode, but does your admin correspond to a single user use of Capella ? It might target a different configuration folder not used as “base” for the multi-user mode, so the multi-user mode would still have a wrong list of detected plugins, or “of plugins to start”.
Could you also indicate which dependencies were missing during your installation attempt ?
Regards
Well, that may prove to be a workaround. But the issue is that currently all that is awfully intransparent. If the dependencies of M2Doc are supposedly clear (in the manifest), then there should be at the minimum a clear error (in the log) during installation of M2Doc plugin unless all dependencies are properly satisfied. So if the OSGI bundle framework does not generate such error but still something is missing at the end that root cause should be looked for and identified… It should not stop at the workaround…