Maven はプラグインを実行する前にプロキシ・プラグインへ到達しなければならない

自動プロキシ・プラグインは、ネットワーク間を移動するノート PC には理想的に聞こえる。しかし厄介な最初の要求が一つある。Maven はプラグイン自体を取得するためにプロキシを必要とするかもしれない。

プラグインのゴールは、Maven がその実装と必要なアーティファクトを解決して読み込んだ後にしか実行されない。実装の内部にあるプロキシ検出は、実装が始まる前に失敗するダウンロードを助けることはできない。完全修飾のプラグイン座標を使えばプレフィックス検索は避けられるが、空のローカルリポジトリにプラグインのアーティファクトが現れるわけではない。

古い Autoproxy Maven プラグインはこの区別を示している。README は proxy-vole によるプロキシ検出を説明するが、そのゴールを呼び出す前にプラグインをローカルにインストールすることも説明している。それはその特定の設計の前提条件と考えるべきで、Maven が一般にブラウザの PAC 設定を読む証拠ではない。

最初の解決に明示的な経路を与える

リポジトリへのアクセスに HTTP プロキシが必要なネットワークでは、その呼び出しが使う Maven 設定で 適切なアクティブ・プロキシ を構成する。許可された公開リポジトリからのブートストラップには、HTTP プロキシ一覧から HTTP 候補を選ぶ。外部経路なしで到達できる承認済みの社内リポジトリも、最初のアクセス問題を解決できる。どちらの方法でも、アプリケーションの依存関係だけでなく、プラグインとその依存関係を対象にしなければならない。

以前に埋まったローカルリポジトリはブートストラップ要件を隠しうる。開発者のノート PC での成功は、新しい CI アカウントが同じビルドを開始できることを証明しない。プラグインの検出ロジックを変える前に、失敗したアーティファクトとフェーズを見る。

プラグインが読み込まれた後の依存関係の失敗は別の問いになる。検出された経路が正しいか、アクティブな Maven トランスポートがその結果の設定を使うか、である。自動検出を残す価値があるかを決めるときは、この二つの失敗点を区別しておく。