Dependency conflict in extension manager for docx4j-ImportXHTML

Help / Discuss
#1

Context:

I would like to be able to automatically build docx (Microsoft Word compatible) files from XWiki. After some research I decided to try to build a component for XWiki as a jar extension using docx4java and also including the docx4j-ImportXHTML project.

So far, so good, I could build my own jar and try to install it through the Extension Manager…

Problem:

It fails because through com.lowagie:itext-2.1.7 it introduces a dependency on bouncycastle:bcmail-jdk14-138 which conflicts with the installed (core extension feature) bouncycastle:bcmail-jdk14/1.60.

Already tried:

  • add an exclusion in my POM. I can still pass my tests (that seem not to use itext) and build my jar, but the extension manager only sees the dependency on docx4j-ImportXHTML, tries to import it and ignore the exclusion that only lies in my own project…
  • search XWiki forums and only found an old thread but could not guess how to use it for my problem.
  • use LibreOffice/OpenOffice export included in XWiki. Unfortunately the size of tables is ignored by the OpenOffice importer (subject of this other post from mine)

Questions:

  • is it possible to exclude dependencies through the extension manager, or solve in any way such a dependency conflict?
  • what could be other solutions to allow a XWiki extension to rely on the docx4j-ImportXHTML project?
  • what could be other solutions to build docx files from XWiki?
#2

Right, looks like version scheme changed a lot when the groupid was moved from bouncycastle to org.bouncycastle and we end up with older versions having a much greater version number… Will need to add a workaround in XWiki to avoid issues like these.

Extension Manager does not support Maven <excludes> right now unfortunately.

Did you try to use a more recent version of itext ? I see 4.x ones (which is a bit scary I admit) versions on Maven central and they don’t have any dependency.

#3

Hi Thomas, thanks for the answer,

Did you try to use a more recent version of itext ?

Unfortunately the bouncycastle (nor itext) dependancies are not in my own POM but deeply inside dependencies from docx4j-ImportXHTML. And as the Extension Manager loads each jar with its own pom, I would have to build at least a custom version of docx4j-ImportXHTML and maybe others, which I am really reluctant to for maintenance reasons… And I try to avoid to use too recent versions because the production xwiki I target is still in 10.x and relies on slf4j 1.7.25 while last versions of most components use 1.7.26 giving others conflicts - ok for this one, I just need to convince to admin to upgrade…

I really hoped that there would be a way to tell the extension manager to just ignore a dependency, which would solve my problem…

#4

You can fix that using <dependencyManagement> (Extension Manager support those). Now the question is more whether or not docx4j-ImportXHTML will be compatible with a 4.x version of itext.

#5

Well I have just read the Maven doc about dependency management, and must admit it is not really clear for me. But what make me think it could be what I need is when you say:

Extension Manager support those

Do you mean that if I put a <dependencyManagement> bloc in my own POM, it could be enough for the extension manager to use it for the transitive dependencies, actually overriding the dependent poms ?

#6

The point of <dependencyManagement> is to force a specific version for a transitive dependency. Unfortunately you can’t use that to remove a transitive dependency.

#7

Ok, just found that itext 4.x was a relocation for itextpdf 5.x, which depends on bouncycastle versions compatibles with xwiki. I will give it a try and report here…

#8

I’m afraid I’m at a dead end…

The xhtmlrenderer 3.0.0 which is a dependance of docx4j-ImportXHTML is not compatible with itext 4.x. And as the groupid has changed from bouncycastle to org.bouncycastle I cannot simple use a <dependencyManagement> bloc to set a version number, but I would really need to either ignore a dependency (which Extension Manager cannot) or fully replace it with a different artifact (which dependencyManagement cannot).

I also found <distributionManagement> in maven POMs which seems to be able to fully replace a dependency. Could Extension Manager support it in addition to <dependencyManagement>?

#9

<distributionManagement> just describe where artifacts are deployed, nothing to do with dependencies.

#10

Note that it’s easy to fix it for your instance (by applying what I fixed in https://jira.xwiki.org/browse/XWIKI-16988 or some other customization) but anyone else who use your extension will still have the issue until a new version of XWiki is released.

The idea is to tell Extension Manager that it already have the dependency, it’s just that it’s not the same id. For that you need to go to WEB-INF/lib and open bcmail xed file, you will find a bunch of “features” listed in there. The issue here is that the version scheme changed so you need to indicate it by adding the corresponding version (which means adding /140 next to each bouncycastle:* feature) as in:

<features>
<feature>bouncycastle:bcmail-jdk16/140</feature>
<feature>bouncycastle:bcmail-jdk15/140</feature>
<feature>bouncycastle:bcmail-jdk14/140</feature>
<feature>bouncycastle:bcmail-jdk13/140</feature>
<feature>bouncycastle:bcmail-jdk12/140</feature>
<feature>org.bouncycastle:bcmail-jdk16</feature>
<feature>org.bouncycastle:bcmail-jdk15</feature>
<feature>org.bouncycastle:bcmail-jdk14</feature>
<feature>org.bouncycastle:bcmail-jdk13</feature>
<feature>org.bouncycastle:bcmail-jdk12</feature>
</features>

Same for any other Bouncy Castle xed file.

#11

Great!

It definitely solves the problem and is much nicer than what I was imagining (build a list of dependant jars, edit it and then copy everything to WEB-INF/lib: maintenance nightmares guaranteed…)

In fact you are a bit cheating the Extension Manager, by telling it that a dependency is already present, which is close to ignoring it.

The good news here, is that as you have already ported it in future versions, I can tell the sysadmins that the patch may not be quite clean and neat, but that it will be automatically included in the future upgrades which save them from maintenance problems.

The downside, is that I will not be able to publish the extension until a next version of XWiki is realeased. Anyway there is still quit a good deal of work to have it in a publiable state…

Many thanks :slight_smile:

#12

Well the dependency is already present in a more recent version. It’s just that Maven is not very good at tracking id changes so we had to invent something on XWiki side.

#13

A last remark.

Simply adding /140 at the end of the lines as suggested by tmortagne did not help: the (red) conflict lines did not disappear.

I had to consistentlly change any reference to the 1.60 version in the xed files with a 140 (in fact I used 160 to only remove one single character). Then the extension manager accepted to say that a 160 version was installed while the itext extension required a 138. It looks like the XWiki instance still works even after all that black magick…

I shall report here for eventual future problems.

#14

This is very suprising. What is the exact version of XWiki on which you tested that ?

#15

I am testing on a 10.11.9 which is the same version as the one of the production instance.

#16

Indeed I indicated the wrong location. <features> is actually the very old way. Now it needs to be fixed in <extensionfeatures> and the version need to be changed to “140” instead of adding “/140” to the id.

#17

Hi Thomas,

Do you mean that I should add new lines with 140 along with the original ones with 1.60 and that I should not change the original <version>1.60</version>? As it currently works without me really knowing how, I dare not change anything…

#18

No I said the version need to changed but not “any reference to the 1.60 version in the xed files” (otherwise you are lying about the version of org.bouncycastle:bcmail-jdk15on which is installed and it might cause issues with some extensions), just those inside <extensionfeatures> and related to the old bouncycastle groupid. As in:

<extensionfeatures>
<feature>
<feature>bouncycastle:bcmail-jdk16</feature>
<version>140</version>
</feature>
<feature>
<feature>bouncycastle:bcmail-jdk15</feature>
<version>140</version>
</feature>
<feature>
<feature>bouncycastle:bcmail-jdk14</feature>
<version>140</version>
</feature>
<feature>
<feature>bouncycastle:bcmail-jdk13</feature>
<version>140</version>
</feature>
<feature>
<feature>bouncycastle:bcmail-jdk12</feature>
<version>140</version>
</feature>
<feature>
<feature>org.bouncycastle:bcmail-jdk16</feature>
<version>1.64</version>
</feature>
<feature>
<feature>org.bouncycastle:bcmail-jdk15</feature>
<version>1.64</version>
</feature>
<feature>
<feature>org.bouncycastle:bcmail-jdk14</feature>
<version>1.64</version>
</feature>
<feature>
<feature>org.bouncycastle:bcmail-jdk13</feature>
<version>1.64</version>
</feature>
<feature>
<feature>org.bouncycastle:bcmail-jdk12</feature>
<version>1.64</version>
</feature>
</extensionfeatures>
#19

Ok, more clear now. Thank you very much for your time and your explainations.

#20

Unfortunately, it does not work. If I do not change the master <version> value, the extension manager finds that its version is 1.60 and refuses any install depending on a 138 version.

I shall try to change those @#&*! version only during the install of my dependant extension and revert to a more correct numbering after…