重複するジャーを扱うベストプラクティスは何ですか

Question

JBPM5.2を私の既存のプロジェクトに含めています。私はいくつかのjarファイルが重複していることに気付きました。以下 はそれは私がたくさんある私の既存の機能を徹底的に回帰テストをしなければならない意味するので、私は、これらのjarファイルをアップグレードすることに熱心ではないよリスト

 
         my  jbpm 
activation-1.1.jar 1.1 1.1 
antlr-2.7.7.jar   2.7.7 2.7.7 
Common-collections 2.1 3.1 
common-io   1.1 1.4 
dom4j-1.6.1.jar   1.6.1 1.6.1 
Jdom-1.0.jar   1.0 1.0 
Jta.jar     1.0 1.1 
Log4j     1.2.15 1.2.14 
Mail.jar   1.4 1.4 

です。基本的に私は安全で簡単な方法を探しています。

これは多くの人が遭遇する非常に一般的な問題だと思います。誰かが私に彼/彼女のアプローチを共有することができますか？展開のあなたのユニットがEARの場合は

Answer 1

いくつかのオプションは、私は（これはアプリの思考のために適用された場合、私はわからない）

1. と考えることができます。 WARには独自のクラスローダがあるので、jarsをwebappにローカライズすることができます。この記事を投稿してくださいJava EE class loading standard

2. JBPMを別のアプリケーションとして単独で展開することも可能です。

3. アップグレード瓶（私の好み）：私はcommons-は*見ることができるものからのみMINORのバージョンでは、あまりにも延期されている唯一のjarファイルです。だから何も心配する必要はありません。スモークテストやシンプルな機能テストはすべてあなたが必要とするものです。

Answer 2

あなたのアプリはjbpmでどのような依存関係になっていますか？ jbpmとjarファイルは、同じクラスローダの下の同じJVMにありますか？もしそうなら、問題があります。アップグレードはの解決策です。

通常、TomcatやJettyなどのWebアプリケーションのようなものでは、サーバーが必要とするライブラリはサーバーのクラスパス上にあります。デプロイされる各Webアプリケーションには、独自のクラスローダーがあります。あなたが依存しているライブラリは、コンテナ自体を汚染しないこのクラスローダで利用できます。