Maven-なぜですか？

一般的にはネットワークのオープンスペース、特にハブラーでは 、Mavenに特化したトピックは1つもありませんでした。 そして、議論があったところはどこでも、フォームの質問が生じました：

• タイプXのプロジェクトで使用できるものは何ですか？
• Ant / Make / shよりも優れているのはなぜですか？
• そして、プロジェクトでantlr / JAX-WS / XDocletを使用したい場合はどうなりますか？

これらの質問はすべて、Mavenが何であり、Mavenが提供するビルド管理の問題を解決するためのどのようなアプローチについての理解が不十分であるGoogleが世界に存在するという無知から生じていると思います。 これは、記事作成者がxml-filesと魅力的なコンソールコマンドの背後にあるアイデアに注ぐ不十分な注意から生まれます。





私にとって、彼らがMavenと言うとき、それは3つのやや疎いものを意味することを理解することは非常に実行可能です：

• POM。 プロジェクトオブジェクトモデル。 プロジェクトモデル-プロジェクトの構成要素とそのライフサイクルの構造を説明します。
• アーティファクトリポジトリ。 ソフトウェアモジュールアセンブリ製品の保管場所とメタデータ。
• mvnユーティリティとそのプラグイン。 実際には、モジュールのライフサイクル管理プロジェクトを組み立てるためのツールです。

それぞれを個別に見て、それらを一緒に使用する方法を理解しましょう。

POM

これは一般的なプロジェクトモデルです。 名前、バージョン、作成者とその連絡先情報、プロジェクトのVCSおよびプロジェクトに一般的に関連付けられているネットワークリソース、プロジェクトのタイプ（たとえば、ライブラリまたはWebモジュール、元の用語ではパッケージングと呼ばれますが、受信したタイプだけでなく、アーティファクト）、プラグインのアセンブリで使用される他のプロジェクトへのリンクとそれらの使用方法の説明。 このモデルの2つのコンポーネントは、私にとって特に重要なようです。

他のモジュールへのリンク

POMは、他のモジュールとの3種類の関係、依存性、包含、および継承を許可します。



依存関係 、この関係は、モジュールのライフサイクルのいくつかの段階で、モジュール依存性のアーティファクトがいくつか必要であると言います（抽象的には、私にとっては怖いです）。 ライフサイクルのどの段階で正確に何が必要かは、いわゆる依存の範囲によって決まります。 Mavenはいくつかの定義済みスコープを理解し、独自のスコープを追加できます。 例として、私は1つのスコープに限定します。コンパイル-コンパイル、テスト実行、および実行の段階でバイナリ依存関係アセンブリが必要であると言います。



包含 -接続されたモジュールはモジュールの不可欠な部分であると言います。 モジュールがライフサイクルの特定の段階を通過するには、そのメンバーもこの段階を通過する必要があります。 Webモジュール、EJBパッケージ、および共有ライブラリを含むエンタープライズモジュールの典型的な例。 明らかに、そのアセンブリには、含まれる各モジュールのアセンブリが必要です。



継承 このような関係は、祖先モデルの相続人部分に移行することを意味します。 転送ルールはやや混乱していますが、基本的には原則が適用されます-祖先モデルパラメータの値が子孫モデルのデフォルトになります。 私の実践の例：プロジェクトをコンパイルするためのJDKバージョン、結果の内部リポジトリ、ソースがエンコーディング標準に対応しているかどうかを検証するための一連のルールをインストールするモジュールが作成されました。プロジェクトモジュールの下。

アセンブリ中に使用されるプラグインの説明

説明は、関連するプラグインの名前、その設定の一部（プラグインによって個別に決定されます）、およびライフサイクルの各フェーズで実際に実行される目標で構成されます（これらの用語の背後にあるアイデアの詳細な説明については、以下を参照してください）。



この要素は、POMの一般的な考え方とは多少異なります。モジュールの宣言的な説明は含まれていませんが、特定のツールでモジュールを組み立てる手順は記載されていません。

まとめ

1. POMは、ソフトウェアモジュールを記述するための一般的な統合モデルです。
2. 個々のモジュールの属性だけでなく、それらの間の高レベルの関係の保存もサポートします。
3. また、モジュールのライフサイクルをサポートするために必要なツールに関する情報も含まれています。

アーティファクトリポジトリ

アーティファクトリポジトリは、ビルド結果の専用リポジトリであり、目的のアーティファクト（名前、バージョン、アーティファクトの種類）の検索を簡素化するように配置されています。 開発者のグループは、モジュールのソースコードのコピーを持たずに相互の作業の結果を使用し、0で依存関係ツリーを構築できます。Maven互換リポジトリは、さまざまなオープンソースプロジェクトの結果を事実上公開するための標準になりました。



プロジェクトモデルを含むpomファイルもアーティファクトであり、誰とでもリポジトリに格納できることに注意してください（実際、少なくともモジュールの識別と依存関係のみを含むそれらの切り捨てられたバージョンは常に格納されます）。 したがって、リポジトリは、リポジトリに格納されているモジュールに関する情報のソースでもあります（配布に最低限必要です）。



だから、彼らは私たちにどんなボーナスを与えますか：

1. アーティファクトの構造化ストレージ、そのカタログ化。
2. アーティファクトの再利用。

ライフサイクル管理ユーティリティ

名前は非常に哀れなものであることが判明しましたが、それは主題の高い使命と複雑さと一致しています。



その機能に飛び込む前に、Mavenでモジュールのライフサイクルを整理する理論に少し精通する必要があります。 ライフサイクルは、アセンブリの初期化から展開までのモジュールに対する一連の操作全体です。 ライフサイクルを渡す過程で、モジュールに対して特定の操作が実行され、いくつかのアーティファクトが形成されます。 ライフサイクルはフェーズに分割されます。 各フェーズでは、モジュールの通過と新しいアーティファクトの出現の結果として、モジュールを新しい状態に移行します。 前の各フェーズは、次のフェーズの基礎を準備します。 フェーズリストは基本的にPOMの一部ですが、すべてのモジュールに共通のグローバルです。 明確なリストを提供するのは無意味ですが、例として、コンパイル、テスト、デプロイの順でいくつかのフェーズを示します（私の意見では、直感的に名前を付けます:)）。



各フェーズ内で、特定のモジュールのモデルに応じて特定の目標セットが実行されます。 ターゲットは、ソースコードやアーティファクトに対する特定の操作です。



次に、ユーティリティ自体について説明します。 彼女は、プロジェクトモデルに基づいてライフサイクルを実装する責任があります。 2つの主要コンポーネントで構成されます。

1. まず、プロジェクトデザインの基本原則、標準プロジェクトタイプのフェーズのデフォルト目標、プラグインの作業環境（モデルへのアクセスインターフェイス、リポジトリ、FS、設定など）を説明する非常に小さなカーネルから.p。）。
2. 第二に、プラグインから。 実際には、目標を達成するコードが含まれています。 ほぼすべての外部mvn機能が実装されています。 生成、コンパイル、テスト、パッケージなど。 など

このユーティリティとの通信は非常に簡単に構築されています。 クライアントモジュールをどのフェーズ条件に持って行く必要があるかを言うだけです。 目標を達成するためのタスクの定式化と完了の複雑さはすべて、プラグイン開発者の良心にかかっています（まあ、モデル開発者には少し残っています）。 たとえば、コンパイルと言うと、VCSから出たものだけでなくコンパイルされますが、たとえばwsimportによって必要なものも生成され、結果もコンパイルされます。



特定のプラグインに対して個別のタスクを実行するように依頼することもできます。 たとえば、Eclipseプロジェクトを生成するためのプラグインがあります。これは、デフォルトでどのフェーズにも関連付けられていない「プロジェクトを生成する」タスクですが、関係者によって手動で呼び出されます。



mvnのもう1つの非常に興味深い機能は、アーキタイプに基づくドラフトプロジェクトの作成です。 アーキタイプは、一般的にその構造と使用されるプラグインに焦点を合わせた汎用プロジェクトテンプレートです。 たとえば、java-library、web-module、およびgrailsアプリケーションなどの非標準の標準アーキタイプがあります。 アーキタイプとプロジェクトタイプの違いを理解することが重要です。 アーキタイプ-プロジェクトの初期構造とプロジェクトの個々の部分のテンプレートのみで、プロジェクトを作成した後、そのアーキタイプに関する情報は残りません。 プロジェクトのタイプ-反対に、ライフサイクル全体で使用されるモデルの一部。

合計はいくらですか

そのため、Mavenの3つの柱を特定しました。 彼らは一緒に何をくれますか？

• 1つの場所および1つの形式でのモジュール情報の集中。 ここではすべてがスムーズではありませんが、多くのIDEはPOMからプロジェクトをインポートできます。ほとんどの自動コンパイルサーバー（XPの支持者が言うように継続的な統合）はプロジェクトを追加するためにも使用できます。
• 統合モジュール識別システム。 非常にシンプルで非常に重要です。 先週の土曜日の23時に収集された、super-projectのbugfix-branchのような指定は現在ありません。
• 1つのツール。 率直に言って、これはMavenのユニークな機能ではありません。 私は抵抗することができず、共通の真実を繰り返すことはできません。プロジェクトは標準的でポータブルな手段で収集されるべきです。 最初のプロジェクト開発者のお気に入りのIDEを組み立てることは、地獄への道です。
• 自動依存関係管理。 プロジェクトのソースコードを何かのバイナリアセンブリにリンクすることは非常に悲しい習慣です。 特に注意が必要なのは、ソースリポジトリのサポートの難しさです（svnバックアップに必要な磁気テープの数は？）））。 ソースコードをドラッグするリポジトリまたは依存関係のスクリプトの形の自転車の発明も、宇宙船が宇宙の広がりを耕す時代には最良の解決策ではありません。
• プロジェクトの設計および組み立てプロセスに関連するソリューションの再利用。 プロジェクトの継承と包含のおかげで、開発されたプロジェクトモデル、インフラストラクチャに関連する設定、および当社で採用されているツールを再利用できます。 アーキタイプを使用すると、新しいプロジェクトの作成段階を自動化し、プロジェクト構造の準備にかかる時間を節約し、外部モデルの使用におけるエラーを最小限に抑えることができます。
• 作業結果とその後の使用の単純さを管理するための既製のツール。 インフラストラクチャを適切に構成し、各ビルドが適切な場所に落ち着き、将来の使用に備えます。 大規模プロジェクトのさまざまなバージョン/モジュールブランチのパフォーマンスを確認する必要がありますか？ POMで依存関係を編集するだけです。

おわりに

私が時々中心的な問題から逸脱し、「どのように」の問題に取り掛かる何かが、まあまあ...



上記のすべての情報から、単純なものを描くことができますが、何らかの理由で非常にまれな結論を導き出します。 Mavenは、Javaアプリケーションを構築するためのユーティリティではありません。 Mavenは、プロジェクトサポートを使用して幅広いタスクを自動化するためのフレームワークです。 言語やプラットフォームとは関係ありません;さらに、何も収集する義務は絶対にありません。 モデルの説明を使用するか、プラグインを記述して、1つまたは別のツールに変換します。 はい、採用されているデフォルトのモデルはJavaモジュールのアセンブリですが、これらはデフォルトに過ぎません...



トピックを読んだ後、誰もが最初に与えられた質問に自信を持って答えられることを願っています;）



PSまた、Mavenのカスタムアプリケーションの使用経験についても興味を持って学びます。 将来、興味深い珍しいユースケースの例を含む投稿を作成するというアイデアがあります。