Maven-2年間の使用後の反射
過去2年間、プロジェクトを構築するためのツールとしてMavenを使用しました。 その結果、私はMavenに非常に不満を感じていたため、現在のプロジェクトをAntに翻訳することを真剣に検討することに不満を感じました。
私の不満の理由を議論する前に、私はMavenについていくつかの言葉を言う必要があります。 詳細は説明せず、主な機能の概要を簡単に説明します。
サイトの説明によると、Mavenはソフトウェアプロジェクト管理ツールです。 実際には、Mavenはプロジェクトのアセンブリを管理するためのシステムであり、Antやmakeなどのツールに似たさまざまな方法で目標を設定します。 Mavenの特徴的な機能は次のとおりです。
ご覧のとおり、理論的には、Mavenは非常に強力で興味深いツールです。 実際には、写真は多少異なって見えます。 もちろん、Mavenにはいくつかの利点がありますが、残念ながら、非常に具体的な欠点も数多くあります。
メリットから始めましょう。 Mavenを使用したアセンブリは非常に簡単です。 プロジェクトのルートでmvn clean installを書くだけで十分です-プロジェクトが組み立てられます！ 必要なライブラリを検索してダウンロードする必要も、スクリプトを勉強する必要もありません。 このチームは、プロジェクトの種類に関係なく常に機能します。
さらに、Mavenはディレクトリ構造を標準化するのに非常に役立つため（読む：非標準の構造で作業することは非常に困難です）、どこにあるのかを常に非常に簡単に理解できます。
プロジェクトはモデルの形で記述されているため、いくつかの興味深いことが可能になります。 たとえば、MavenプロジェクトからEclipseなどのプロジェクトを自動的に作成できます。この場合、Eclipseプロジェクトですべてのディレクトリが正しく構成され、ライブラリが接続されます。
この利点のリストで終わります。 不利な点に目を向けます。
Mavenの文書化は不十分です。 ドキュメントはそこにあるようですが、多くの質問に対する答えを見つけることはほとんど不可能です。 これは、Mavenとそのプラグインの両方に適用されます。 さらに、「Maven：the definitive guide」という本でさえ、多くのことを明確にしているが、多くの疑問を残している。
Mavenはおしゃべりですが、同時にわかりにくいです。 標準モードでは、通常は完全に不要な、アセンブリ中にあらゆる種類の情報が大量に表示されます。 デバッグモードは単なる災害です！ このモードのプロジェクトでは、Mavenはアセンブリ中に8万行以上を表示しました！ 同時に、多くの場合、エラーメッセージと問題は非常に霧が深く、不可解です。
プロジェクトモデルは長く、読みにくく、修正が困難です。 XMLベースの退屈な構文 モデルの継承。その結果、いくつかのモデルを見て、最終的にアセンブリで使用される構成を決定する必要があります。 モデルのさまざまな部分での構成のスミアリングは、この状況につながる要因の完全なリストとはほど遠いものです。
ビルドプロセスは外部システムに依存します。 すなわち-リポジトリから。 私は、1人の新しい従業員がプロジェクトの組み立てに原因不明の問題を抱えていた場合がありました。 最終的に、リポジトリの1つがURLを変更したことが判明しました。 Mavenが既に必要なものすべてをダウンロードできた人は何も気づきませんでした。 しかし、新しい従業員はプロジェクトを組み立てることができませんでした。
アセンブリプロセス中のMavenは、膨大な数のさまざまなファイルをダウンロードします。 実際、Maven依存関係管理システムの要素の1つはローカルリポジトリです。 アセンブリに必要なものはすべて、Mavenはこの非常にローカルなリポジトリにダウンロードしてインストールします。 一方で、それは良いことです。複数のプロジェクトでライブラリが必要な場合、ライブラリは一度だけダウンロードされ、Mavenはこのローカルリポジトリからそれを取得します。 一方、ダウンロードされた量は驚くべきものです。 たとえば、約5つの異なる（ただし同じタイプの）プロジェクトを収集した作業コンピューターでは、リポジトリは1ギガバイト以上を占有し、4万5千のファイルとディレクトリが含まれています！
Mavenは、「ニアアセンブリ」タスクの自動化にはあまり適していません。 私はしばしば、異なるプロジェクトで、メインアセンブリに関連しないことが多く、自動化を必要とするいくつかのアクションに遭遇しました：プロジェクトのある部分から別の部分にファイルをコピーする、アナライザーでコードを処理する、いくつかのディレクトリをきれいにするなどです。 Antを使用したとき、プロジェクトに追加の目標を作成しました-すべてが順調でした（まあ、はい、プロジェクトは複雑でしたが、すべてが文書化されていました）。 Mavenはそのような機会を与えません。
アセンブリシーケンスに関する非常に厳しいMavenアプローチは、このシーケンスから少なくとも1ステップ離れる必要がある場合に大きな困難を生じます。 たとえば、ある時点で、同じモジュールを異なる設定で2回コンパイルし、2つの結果を異なる名前で異なる場所に配置する必要がありました。 それは非常に重要なことがわかりました。
Mavenの理解と習得は困難です。 理由-上記のすべて。
Mavenの機能は、ほとんどの場合、メリットよりも多くの問題をもたらします。 おそらく、Mavenは、プロジェクトの構造の変更がほとんど発生していない安定したフェーズのプロジェクトに適している可能性があります。 プロジェクトのアクティブフェーズで、アセンブリプロセスがまだ完全に形成されていない場合-新しいモジュールが追加され、部品が移動している-Mavenは無限の頭痛の種になります。
私自身はMavenの使用を放棄し、 Ant + Ivyの組み合わせに切り替えたいと考えています。 Antはプロジェクトの構築で素晴らしい仕事をし、Ivyは依存関係を管理する機能を追加します。これは、他のツールには非常に欠けていたMavenの機能そのものです。
私の不満の理由を議論する前に、私はMavenについていくつかの言葉を言う必要があります。 詳細は説明せず、主な機能の概要を簡単に説明します。
Mavenとは何ですか？
サイトの説明によると、Mavenはソフトウェアプロジェクト管理ツールです。 実際には、Mavenはプロジェクトのアセンブリを管理するためのシステムであり、Antやmakeなどのツールに似たさまざまな方法で目標を設定します。 Mavenの特徴的な機能は次のとおりです。
- 構成よりも規約の優位性。 プロジェクトが特定の基準に従っている場合、Maven自身がプロジェクトを組み立てるために何をどのように行うかを理解します。 プロジェクトの説明は、標準と異なるもののみを示します（たとえば、非標準のディレクトリ構造）。
- 依存関係管理 プロジェクトを組み立てる（または実行する）ために追加のライブラリが必要な場合は、プロジェクトの説明でそれらを指定するだけで十分です-Mavenはそれらをダウンロードし、必要なバージョンを把握し、これらのライブラリが他のライブラリに依存している場合、Mavenそれらをダウンロードします。 このために、Mavenはライブラリとその説明が保存されているリモートリポジトリ（リポジトリ、リポジトリ）を使用します。
- 記述言語。 他の同様のツールとは異なり、MavenはPOMと略されるProject Object Modelと呼ばれるプロジェクトの説明を正確に使用します（これを「プロジェクトモデル」と呼びます）。 モデルは、プロジェクトを組み立てるために何を、どのように、いつ完了する必要があるかを示していません。 代わりに、プロジェクトの構造、依存関係などを説明します。 Mavenは、この情報に基づいてプロジェクトをどのようにアセンブルするかを独自に決定すると想定されています。
- リジッドアセンブリシーケンス図。 Mavenは、すべてのプロジェクトのアセンブリがいくつかのタイプのアセンブリシーケンスに適合することを提案します（Mavenの用語では「ライフサイクル」、ライフサイクル）。 シーケンスは特定のフェーズ（リソースの処理、コンパイル、テスト、パッケージング、インストールなど）で構成され、プロジェクトは厳密に指定された順序で渡されます。 プロジェクトモデルでは、1つまたは別のフェーズで実行する必要のある特定の詳細を指定します（「コンパイル時にこれらのコンパイラオプションを使用」...）。
現実
ご覧のとおり、理論的には、Mavenは非常に強力で興味深いツールです。 実際には、写真は多少異なって見えます。 もちろん、Mavenにはいくつかの利点がありますが、残念ながら、非常に具体的な欠点も数多くあります。
メリットから始めましょう。 Mavenを使用したアセンブリは非常に簡単です。 プロジェクトのルートでmvn clean installを書くだけで十分です-プロジェクトが組み立てられます！ 必要なライブラリを検索してダウンロードする必要も、スクリプトを勉強する必要もありません。 このチームは、プロジェクトの種類に関係なく常に機能します。
さらに、Mavenはディレクトリ構造を標準化するのに非常に役立つため（読む：非標準の構造で作業することは非常に困難です）、どこにあるのかを常に非常に簡単に理解できます。
プロジェクトはモデルの形で記述されているため、いくつかの興味深いことが可能になります。 たとえば、MavenプロジェクトからEclipseなどのプロジェクトを自動的に作成できます。この場合、Eclipseプロジェクトですべてのディレクトリが正しく構成され、ライブラリが接続されます。
この利点のリストで終わります。 不利な点に目を向けます。
Mavenの文書化は不十分です。 ドキュメントはそこにあるようですが、多くの質問に対する答えを見つけることはほとんど不可能です。 これは、Mavenとそのプラグインの両方に適用されます。 さらに、「Maven：the definitive guide」という本でさえ、多くのことを明確にしているが、多くの疑問を残している。
Mavenはおしゃべりですが、同時にわかりにくいです。 標準モードでは、通常は完全に不要な、アセンブリ中にあらゆる種類の情報が大量に表示されます。 デバッグモードは単なる災害です！ このモードのプロジェクトでは、Mavenはアセンブリ中に8万行以上を表示しました！ 同時に、多くの場合、エラーメッセージと問題は非常に霧が深く、不可解です。
プロジェクトモデルは長く、読みにくく、修正が困難です。 XMLベースの退屈な構文 モデルの継承。その結果、いくつかのモデルを見て、最終的にアセンブリで使用される構成を決定する必要があります。 モデルのさまざまな部分での構成のスミアリングは、この状況につながる要因の完全なリストとはほど遠いものです。
ビルドプロセスは外部システムに依存します。 すなわち-リポジトリから。 私は、1人の新しい従業員がプロジェクトの組み立てに原因不明の問題を抱えていた場合がありました。 最終的に、リポジトリの1つがURLを変更したことが判明しました。 Mavenが既に必要なものすべてをダウンロードできた人は何も気づきませんでした。 しかし、新しい従業員はプロジェクトを組み立てることができませんでした。
アセンブリプロセス中のMavenは、膨大な数のさまざまなファイルをダウンロードします。 実際、Maven依存関係管理システムの要素の1つはローカルリポジトリです。 アセンブリに必要なものはすべて、Mavenはこの非常にローカルなリポジトリにダウンロードしてインストールします。 一方で、それは良いことです。複数のプロジェクトでライブラリが必要な場合、ライブラリは一度だけダウンロードされ、Mavenはこのローカルリポジトリからそれを取得します。 一方、ダウンロードされた量は驚くべきものです。 たとえば、約5つの異なる（ただし同じタイプの）プロジェクトを収集した作業コンピューターでは、リポジトリは1ギガバイト以上を占有し、4万5千のファイルとディレクトリが含まれています！
Mavenは、「ニアアセンブリ」タスクの自動化にはあまり適していません。 私はしばしば、異なるプロジェクトで、メインアセンブリに関連しないことが多く、自動化を必要とするいくつかのアクションに遭遇しました：プロジェクトのある部分から別の部分にファイルをコピーする、アナライザーでコードを処理する、いくつかのディレクトリをきれいにするなどです。 Antを使用したとき、プロジェクトに追加の目標を作成しました-すべてが順調でした（まあ、はい、プロジェクトは複雑でしたが、すべてが文書化されていました）。 Mavenはそのような機会を与えません。
アセンブリシーケンスに関する非常に厳しいMavenアプローチは、このシーケンスから少なくとも1ステップ離れる必要がある場合に大きな困難を生じます。 たとえば、ある時点で、同じモジュールを異なる設定で2回コンパイルし、2つの結果を異なる名前で異なる場所に配置する必要がありました。 それは非常に重要なことがわかりました。
Mavenの理解と習得は困難です。 理由-上記のすべて。
結論
Mavenの機能は、ほとんどの場合、メリットよりも多くの問題をもたらします。 おそらく、Mavenは、プロジェクトの構造の変更がほとんど発生していない安定したフェーズのプロジェクトに適している可能性があります。 プロジェクトのアクティブフェーズで、アセンブリプロセスがまだ完全に形成されていない場合-新しいモジュールが追加され、部品が移動している-Mavenは無限の頭痛の種になります。
私自身はMavenの使用を放棄し、 Ant + Ivyの組み合わせに切り替えたいと考えています。 Antはプロジェクトの構築で素晴らしい仕事をし、Ivyは依存関係を管理する機能を追加します。これは、他のツールには非常に欠けていたMavenの機能そのものです。
All Articles