3

コンパイルとデプロイメントのjar依存関係を管理する適切な方法について一般的な質問があります。私は通常、単純なライブラリ/アプリケーション用に次のようなdevディレクトリをレイアウトします。

Calculator
   src
   test
   build
   lib
   …

これを行うには多くの方法がありますが、これは一般的なプロジェクトの私の典型的なレイアウトです。私の質問はlibディレクトリを中心に展開しています。私は通常、プロジェクトが依存しているjarをlibディレクトリ（log4jなど）に配置します。したがって、コンパイル時に、さまざまなパスをlib\log4j.jarなどに設定できます。配布可能なパッケージを作成するとき、私はこのレイアウトを反映する傾向があります。

dist
   Calculator.jar
   lib
      log4j.jar
      addition.jar
      subtraction.jar

これにより、メインjarの場所を基準にしてクラスパスを設定するスクリプトを設定するか、メインjar（この場合はCalculator.jar）のマニフェストにクラスパスを設定できます。これが最善の方法である場合とそうでない場合があります。これを行うが、それは私にとってはうまくいき、私がこれについて話し合った他の開発者によって依存関係を処理するための受け入れられた方法のようです。

私の質問は、私がこのようにレイアウトした他のプロジェクトを利用する新しいプロジェクトを作成したいときに起こります。

したがって、上記のサンプルのCalculatorプロジェクトを使用する新しい計算機プロジェクトを作成するとします。同じレイアウトに従うと、次のようになります。

dist
   ScentificCalculator.jar
   lib
      Calculator.jar
      lib 
         Log4j.jar
         addition.jar
         subtraction.jar

もちろん、これは依存関係ツリーが深くなると手に負えなくなる可能性があります。

SuperWhizBangCalculator.jar
lib
   ScientificCalculator.jar
   lib 
      Calculator.jar
      lib
         log4j.jar
         addition.jar
         subtraction.jar

別のオプションは、ツリーを平らにすることです。

SuperWhizBangCalculator
   lib
      ScientificCalculator.jar
      Calculator.jar
      log4J.jar
      addition.jar
      subtraction.jar

しかし、これについて何かが正しくないようです。どのライブラリがどのコンポーネントに依存しているかを示す構造が失われます。だから私は、これを行うためのコミュニティ主導の標準的な方法があるかどうか疑問に思いました。一度のサイズがすべてに適合することは決してないということを理解しています。

時間をありがとう...

4

7 に答える 7

1

コミュニティ主導の標準が見つかるとは思いませんが、全体としてlib-in-a-libを持つのは良い考えではないと思います。プロジェクトに共通する多くのjarファイルを複製するリスクがあります。これはディスクスペースを浪費し、クラスパスの最初にないjarをアップグレードするリスクをもたらします...

私はあなたの3番目のオプションが最良のものだと思います。

また、Eclipseが2つの異なるプロジェクト間のリンクをどのように管理するかについても考えてみます...プロジェクトを別のプロジェクトのビルドパスに配置できます...

于 2010-03-02T05:34:26.687 に答える
1

ここには2つのタイプがあります

  1. log4jなどのサードパーティライブラリとの外部依存関係
  2. プロジェクト内の内部依存関係

理想的には、内部依存関係用のlibディレクトリが必要です。展開計画を作成するときに、外部依存関係を動的に構築する必要があります。

于 2010-03-02T05:59:26.787 に答える
1

別の答えをエコーするために、「なぜMavenを使用しないのですか？」

Mavenはすべての依存関係を管理し、別のプロジェクトがjarを使用したい場合は、はるかに簡単に使用できます。Javaの世界にビルド、レイアウト、依存関係の標準がある場合、それはMavenです。

于 2010-03-02T17:47:48.183 に答える
1

最後のオプションであるフラット lib ディレクトリに進みます。これは、依存関係を持つオープン ソース プロジェクトをダウンロードした場合に見つかるものです (関連する JAR が多数ある場合は、別のレベルのサブディレクトリを使用する場合があります)。

ディレクトリ構造と依存関係管理を混同しないでください。これらは完全に別のものです。スマートな依存関係管理が必要な場合は、Maven、Ivy を使用した ANT、または明示的な依存関係 (OSGi) を持つモジュール システムなどを検討する必要があります。

于 2010-03-02T18:06:52.963 に答える
1

あなたの質問に直接答えません。しかし、「依存関係の管理」のほとんどを行うことができる Apache の Maven 2 を見ることができます。

Maven 2 を立ち上げ、実行し、動作させるには、ある程度の学習曲線があることに注意してください :)

それ以外は、3 番目のオプションが理にかなっています。

于 2010-03-02T17:43:01.253 に答える
0

私は絶対に最後のアプローチで行きます。両方ともDを使用するライブラリBとCを使用するプログラムAを想像してみてください。構造化されたレイアウトでは、バージョンの競合を懇願しているDの2つのインスタンスがあります。

于 2010-03-02T05:41:53.953 に答える
0

重要な情報は、クラスがどのようにロードされるかです。「java -jar SuperWhizBang.jar」の状況では、すべてのクラスをロードする 1 つのクラスローダーがあります。次に、依存関係をマージすることは完全に理にかなっています。

別々のクラスローダを持つことを選択した場合、階層は良い考えです。これは通常、OSGi 設定で発生しますが、ソリューションにとってはおそらくやり過ぎです。

于 2010-03-02T18:25:10.797 に答える