Dependency conflict in extension manager for docx4j-ImportXHTML

And that’s the case. But it’s supposed to compare to the feature version and not to the main extensions. Most probably a bug in 10.11.9 which was fixed since (I vaguely remember something like this), will try to reproduce when I find some time.

Just for refence with 10.11.9, if I put back the correct version number in BouncyCastle extensions, iText extension (and all my dependant ones) refuses to load at start time with the following error message:

[main] WARN ltInstalledExtensionRepository - Invalid extension [com.lowagie:itext/2.1.7] on namespace [wiki:xwiki] (InvalidExtensionException: Dependency [bouncycastle:bcmail-jdk14-138] is incompatible with the core extension [org.bouncycastle:bcmail-jdk15on/1.60])

Looks like I will have no clean solution on 10.11.9 :frowning:

I will still continue testing with the odd version numbers on 10.11.9 but really think that upgrade time has arrived


For future readers, the installation way that seems to work is:

  1. before changing anything in xed files, install org.bouncycastle:bctsp-jdk14 version 1.46 on which iText 1.2.17 depends
  2. change the numbers in xed files for bcmail-jdk15on-1.60.xed and bcprov-jdk15on-1.60.xed for bouncycastle extensionfeatures and the main <version> bloc
  3. find the bctsp-jdk14.xed file under the /data/extensions/repository folder and add it an extensionfeature and a feature bloc mimicing the one from bcprov-jdk15on-1.60.xed. Do not forget to change the main <version> bloc too.
  4. at that moment, install normally the docx4j-ImportXHTML extension

Definitely ugly because from now on, you cannot install anything depending on BouncyCastle, because in the end the system will choke with the inconsistent version numbers

The simplest in your case is most probably to put docx4j-ImportXHTML jar (and missing jar it needs like xhtmlrenderer from what I understood) in WEB-INF/lib, i.e. make them core extensions too. XWiki trust those and does not try to validate them (it does not have any control over them anyway, impossible to unload them for example).

By the way, which version of docx4j-ImportXHTML are you trying to install ?

So I just tried the <extensionfeatures> fix I suggested but in 11.10.2 and it works as expected (that’s reassuring) for the problem we discussed but I actually hit a very different problem: itext 2.1.7 have a dependency on bctsp-jdk14 138… which does not exist (the pom exists but not the JAR). Looks like it was fixed in following versions. Since XWiki does not package bctsp (simply because it does not need it) it cannot automatically “fix” this nonsense with some <extensionfeatures> magic.

My problem is that the magic of maven have driven me to be rather lazy, and I prefere when the system take cares of the dependencies :wink: . More exactly, there are many more dependencies listed in the dependency hierarchy but fortunately they are already present so you are true adding itext, xhtmlrenderer and bctsp-jdk14 in WEB-INF lib would certainly be enough, but I was not sure of that when I first tried. And for pushing it into a production system, I would have to set up a manual registration of the added jars and their versions as long the dependency tree, when the extension manager give it for free.

For docx-ImportXHTML I am using the last version which depends on slf4j 1.7.25, so the 6.1.0 and 6.1.2 for docx4j. I will change to the last 8 .x series when the production XWiki will upgrade to a 11.x version.

For bctsp-jdk14 it looks to be a maven trick I was not aware of: a <distributionManagement><relocation> bloc. Maven knows about it and automatically fetched the jar from the org.bouncycastle group. But the extension manager apparently does not processes that. IMHO it seems to be scarcely used, so I really wonder whether it should ever be implemented…

Right, I did not even checked. I was expecting Maven Resolver (the library XWiki uses to resolve Maven artifacts) was taking care of it but looks like we need to do it on our side. Just fixed it in https://jira.xwiki.org/browse/XCOMMONS-1858.

Yes the coverage of this use case is definitely not great right now. The problem is that, while it’s easy for a build system, taking care of the exclusion logic is a bit more complex for a runtime system. The good new is that we plan to work on that in 12.x (so somewhere in 2020).

Thank you for this info. Knowing that a true solution should come in 12.x version, the current workaround is now fully acceptable.

PS: sorry for the delay to answer, I was on vacation…