私の Jenkins ビルドの 1 つで、かなり複雑なビルド ワークフローがあります。プロジェクトには 2 つのモジュールが含まれています。モジュール M1 はサービスを構築し、モジュール M2 はサービス クライアントを構築します。M1 は M2 に依存しています (理由は聞かないでください)。M2 には、M1 の ejb から作成されたスタブが必要です。そのため、次のビルド順序で回避しようとした循環依存関係にあります。
- mvn clean install (プロジェクト全体)
- mvn package -PCI (M1 jar を含むすべての依存関係を収集するプロファイルを持つ M2 用)
- スタブを作成するためにビルド アーティファクトと依存関係を別のマシンにコピーする
- スタブを作成する
- スタブを含むバージョンで M2 ビルド アーティファクトを上書きする
- mvn install:install (M2用)
最終インストールを実行すると、次のように爆発します。
[INFO] [install:install {execution: default-cli}]
[INFO] -------------------------------- ----------------------------------------
[エラー] ビルド エラー
[情報] -- -------------------------------------------------- --------------------
[情報] このプロジェクトのパッケージ化では、ビルド アーティファクトにファイルが割り当てられませんでした
[情報] ---------- -------------------------------------------------- ------------
そこで、私はすでに Jenkins を使用していて、とにかくスナップショット ディレクトリにデプロイしているので、心配する必要はなく、スナップショット リポジトリから新しいバージョンを取得するため、ローカル デプロイを省略できるという考えを思いつきました。その結果、Jenkins はインストールの実行後にジョブのアーティファクトをアーカイブしました。最終インストールを実行しなかったため、スタブのないバージョンがデプロイされました (ステップ 2 からだと思います)。
次に、Maven 統合の自動アーカイブ機能に加えて、ビルド後のオプションを使用してサービス クライアント jar を明示的にアーカイブするように Jenkins ジョブを構成しました。その結果、Jenkins ジョブ用にサービス クライアント jar をアーカイブしました。1 つはプロジェクト レベル (スタブを含む目的のバージョン) で、もう 1 つは M2 (スタブなし) でした。もちろん、スタブなしのバージョンがデプロイされました。
プロジェクト構造を変更せずに、このジレンマから抜け出す方法を教えてください。開発者の要望が満たされる限り、pom ファイルに何かを追加することができます。Jenkins の仕事は私のドメインです。