3

この場合を想像してみてください。私はMavenで管理しているオープンソースプロジェクトを持っていますが、それはMavenリポジトリにない有名なライブラリ（jpathwatchなど）に依存しています。どうすればそれを機能させることができますか？

簡単な方法は、jpathwatchをローカルのMavenリポジトリにインストールすることです。しかし、それは私のプロジェクトのソースコードをチェックアウトし、彼ら自身でそれらを構築したい人々に負担を課します。彼らはMavenエラーに遭遇し、次にREADMEファイルを調べるか、または単に試行をあきらめます。

私がそれを回避するためのクリーンな方法はありますか？ANTに戻る必要がありますか？

4

4 に答える 4

2

これを行う最もクリーンな方法は、ライブラリを中央にアップロードすることです (または、プロジェクトがオープンソースでない場合は、プロジェクトがホストされている maven リポジトリに失敗します)。

元のプロジェクトが望まない場合にアーティファクトをアップロードする方法を詳しく説明した、サードパーティのアーティファクトをセントラルにアップロードするためのガイドがあります。

独自の groupId の下にアーティファクトを展開する可能性もあります... 最後の手段、または公式の方法が遅すぎると思われる場合の最初の手段です。

良きオープン ソースの市民になりたい場合は、そのようなものを中央にアップロードして、他の人が恩恵を受けるようにしてください。

プロジェクト内リポジトリのようなハックは、企業のリポジトリ マネージャーの背後に住んでいて<mirrorOf>*</mirrorOf>、~/.m2/settings.xml(あるべき姿で) 持っている人には機能しません。

スコープのようなハックは、人々があなたのプロジェクトを推移的な依存関係としてsystem操作しようとすると、終わりのない苦痛の世界を引き起こします.なぜなら、あなたのプロジェクトをリアクターからではなくローカルリポジトリから解決するときに何が評価されると思いますか? サードパーティのjarファイルを置いた場所ではないことを確認してください。${basedir}~/.m2/repository/your-groupId/your-artifactId/your-version

スコープ ハックは、最終的なアーティファクトを構築している場合にのみ機能し、そのsystem場合でも、意図しない副作用が発生する可能性があります (JAR マニフェストに焼き付けられるクラスパスのように...マシンのディスク上のパスになります...そうではありませんユーザーがデプロイするパス)

解決策は次の 3 つだけです。

  1. リモートリポジトリにデプロイします (優先度は中央に移動します)
  2. ローカルリポジトリにインストールします（エンドユーザーにとっては苦痛です）
  3. 偽のモジュール ソリューション (JAR モジュールを偽造し、「ビルドされた」jar をサブインしたい jar に置き換えて、モジュールをビルドせずにビルドされたアーティファクトにする...これはオプション 1 になります。または2ですが、「プロジェクトリポジトリ内」よりも害の少ないソリューションです）
于 2013-01-21T12:45:20.650 に答える
1

このような場合、このライブラリをプロジェクトにバンドルし、次の<system>ように依存スコープを利用する必要があります。

<dependency>
    <groupId>...</groupId>
    <artifactId>...</artifactId>
    <version>...</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/lib/file.jar</systemPath>
</dependency>
于 2013-01-21T09:59:33.967 に答える
0

プロジェクト内リポジトリを作成できます。

Leonid Dubinsky のブログ - Maven プロジェクト内リポジトリを参照してください。

于 2013-01-21T09:57:52.457 に答える
0

JAR ファイルをネット上のどこかに置き、それをプロジェクトから参照するのは簡単です。3 つの簡単な手順で独自の Maven リポジトリを作成できます。私の投稿を参照してください。

于 2013-01-21T09:59:11.923 に答える