如何在pom.xml中使用两个版本的itext jar文件？

Question

In my project i have dependencies displaytag and birt-runtime . And here display tag needs itext-2.0.1.jar and birt-runtime needs itext-2.1.7.jar so how can i declare this in my pom.xml to use itext-2.0.1.jar only by displaytag and use itext-2.1.7.jar only by birt-runtime . could some one let me know how to achieve this? Thanks in advance.

Answer 1

In normal java application this is not possible, because in the application itext 2.1 and 2.0 will share the same classloader. But normally, java-apis take care about backward-compatibility, so it should be possible to include only 2.1.

If not, you need multiple classloaders and then it will become complicated.

Existing solutions:

• You could try to add an OSGi container to your application and run both dependencies as a separate osgi-bundle.
• If you run a jboss application server, you could create one module with displaytag and another one with birt-runtime.

DIY:

• I've never done this but you could try to create to manage your own classloaders in your application and load the dependent jars into each own classloader. This article seems to cover the topic.

Answer 2

Short answer: you can't.

Long answer: Maven is a build tool and has no effect on runtime class loading in your application. Normally what it generates is one (or more) artifact(s), tipically jar or war files that may or may not contain your project's dependencies (depending on your POM files).

What you want to achieve is done at runtime by class loaders but under normal circumstances you don't want to tamper with class loading.

What you could do is:

1. Exclude unnecessary transitive dependencies of a dependency in your pom by defining exclusions , this way only one version of itext would be used. Of course, this only works if your dependencies don't rely on the internals of itext and their public API's are compatible but this might be the cleanest and easiest solution.

2. Use a framework/container that has stronger control over class loading, such as an OSGi container. These container provide bundles (somewhat equivalent to artifacts) with "private" class loaders enabling your application having multiple versions of the same library loaded that don't interfere with each other. This solution, however, has other disadvantages and I would only recommend this if you're already familiar with OSGi.