なぜMavenにそんなに悪い担当者がいるのですか？
Mavenがいかに悪いかについては、インターネット上で多くの話があります。数年前からMavenのいくつかの機能を使用していますが、私の見解で最も重要な利点は依存関係の管理です。
Mavenのドキュメントは十分ではありませんが、一般的に何かを達成する必要がある場合、一度理解してから動作します（たとえば、jarへの署名を実装したとき）。 Mavenは素晴らしいとは思いませんが、Mavenがないと本当に苦痛になる問題を解決できます。
それでは、なぜMavenの評判が悪いのか、そして今後Mavenでどのような問題が発生するのでしょうか？たぶん、私が知らないより良い代替案がありますか？ （たとえば、私はIvyを詳細に見たことはありません。）
注：これは議論を引き起こそうとする試みではありません。 FUDをクリアする試みです。
私は約6ヶ月前にMavenを調べました。私たちは新しいプロジェクトを始めていましたが、サポートするレガシーがありませんでした。それは言った：
- Mavenはオールオアナッシングです。または、少なくともドキュメントからわかる限り。 Mavenをantのドロップイン置換として簡単に使用することはできず、徐々により高度な機能を採用できます。
- ドキュメントによると、Mavenは超越的な幸福であり、それはあなたのすべての野生の夢を実現させます。悟りを開く前に、マニュアルを10年間黙想する必要があります。
- Mavenは、ビルドプロセスをネットワーク接続に依存させます。
- Mavenには無駄なエラーメッセージがあります。 Antの「ターゲットxはプロジェクトyに存在しません」とmvnの「無効なタスク「実行」を比較します。有効なライフサイクルフェーズ、またはplugin：goalまたはpluginGroupId：pluginArtifactId：pluginVersion：goalの形式で目標を指定する必要があります。詳細については、-eを指定してmvnを実行することをお勧めします。つまり、同じメッセージを出力し、次にBuildFailureExceptionのスタックトレースを出力します。
私のmavenに対する嫌悪の大部分は、Better Builds with Mavenからの次の抜粋で説明できます。
誰かがMavenが何であるかを知りたいとき、彼らは通常「Mavenとは正確には何ですか？」と尋ねます。 「まあ、それはビルドツールまたはスクリプトフレームワークです」Mavenは、3つ以上の退屈で刺激のない言葉です。アイデア、標準、およびソフトウェアの組み合わせであり、Mavenの定義を単純に消化されたサウンドバイトに変換することは不可能です。革命的なアイデアは言葉で伝えるのが難しい場合があります。
私の提案：アイデアを言葉で伝えることができない場合、そのテーマについて本を書こうとしないでください。私はアイデアをテレパシーで吸収するつもりはありません。
- それは最初からあなたに堅い構造を課します。
- XMLベースなので、ANTと同じくらい読みにくいです。
- エラー報告は不明瞭であり、問題が発生した場合は立ち往生します。
- ドキュメントは貧弱です。
- それは難しいことを簡単にし、簡単なことを難しくします。
- Mavenビルド環境を維持するのに時間がかかりすぎるため、すべてを歌うビルドシステムを持つというポイントを打ち破ります。
- Mavenでバグを見つけて、何か間違った設定をしていないことを理解するには長い時間がかかります。そして、バグは存在し、驚くべき場所にあります。
- それは多くを約束しますが、美しく魅惑的ですが、感情的に冷たくて操作的な恋人のようにあなたを裏切ります。
私は確かに mavenについての雌犬とうめき声 過去に。しかし、今、私はそれなしではいられません。メリットは問題をはるかに上回っていると思います。主に：
- 標準化されたプロジェクト構造。
- 新しい開発者がプロジェクトに参加するとします：
- あなたがそれがMavenプロジェクトであると言うとき、開発者はプロジェクトのレイアウトとプロジェクトの構築とパッケージ化の方法を知っています
- Antプロジェクトだと言うと、開発者はさらに説明するのを待つか、build.xmlを調べて物事を把握する必要があります。
- もちろん、Antを使用して全社標準を課すことは常に可能ですが、私は頻繁に、ことわざを再発明することになると思います。
- 新しい開発者がプロジェクトに参加するとします：
- 依存関係管理。
- 外部ライブラリだけでなく、内部ライブラリ/モジュールも使用します。 Nexus や Artifactory などのMavenリポジトリプロキシサーバーを使用してください。
- Ivy でこれのいくつかを行うことができます。実際、依存関係の管理だけが必要な場合は、おそらくIvyを使用したほうがよいでしょう。
- 特にプロジェクト内。小さなサブプロジェクトを分割することは非常に便利であり、mavenはこれをうまく処理します。アリではもっと難しいです。
- 標準化された成果物管理（特に nexus または artifactory と組み合わせて）
- リリースプラグインは素晴らしいです。
- EclipseとNetBeansの統合は非常に優れています。
- hudson との統合は素晴らしいです。特に、findbugsなどの傾向グラフ。
- 些細な点ですが、mavenがデフォルトでjarまたはwar（ファイル名だけでなく）のバージョン番号insideなどの詳細を埋め込むという事実は非常に重要です役に立ちました。
私にとっての欠点は主に次のとおりです。
- コマンドラインはまったく役に立ちません。これにより、そもそも多くのことができなくなりました。
- XML形式は非常に冗長です。なぜそうなったのかはわかりますが、それでも読むのは苦痛です。
- ただし、IDEで簡単に編集できるXSDがあります。
- 最初は頭を動かすのは難しいです。たとえば、ライフサイクルなど。
- mavenの決定的なガイド は、しかし良い紹介です。
私は、Mavenを知るために少し時間を費やす価値があると本当に信じています。
2つの大きなプロジェクトからの私の実際の経験は、Maven 1からMaven 2への500時間の努力を除いて、Maven関連の問題で各プロジェクトに1000〜1500時間を費やしたことです。
それ以来、私は絶対にMavenが嫌いだと言わなければなりません。それについて考えるとき、私はイライラしています。
Eclipseの統合はひどいです。 （たとえば、Eclipseが生成されたコードと同期し、完全な再構築が必要になるなど、コード生成に無限の問題がありました。責任はmavenとEclipseの両方ですが、Eclipseはmavenやemacsよりも便利です。 Eclipseは残り、Mavenは行かなければなりません。）
多くの依存関係があり、発見したように、構文エラーは実際にはかなり頻繁にパブリックMavenリポジトリにコミットされ、貴重な時間を無駄にすることがあります。毎週。回避策は、プロキシまたはローカルに管理されたリポジトリを使用することであり、それを正しく行うにはかなりの時間がかかりました。
Mavensプロジェクトの構造は、Eclipseでの開発にはあまり適しておらず、Eclipseでのビルド時間が長くなります。
コード生成と同期の問題の影響で、かなり頻繁にスクラッチから再構築する必要がありました。コード/コンパイル/テストサイクルを無限のコンパイル/ウェブサーフィン/スリープ/ダイ/コードサイクルに減らし、90年代に戻り、 40分のコンパイル時間。
Mavenの唯一の言い訳は依存関係の解決ですが、すべてのビルドではなく、たまにそれをしたいと思います。
要約すると、mavenは、可能な限りKISSから離れています。また、支持者は、年齢が素数であるときに誕生日に余分に祝うタイプの人々である傾向があります。自由に投票してください:-)
Mavenは素晴らしいです。私の意見では、その評判の理由は急な学習曲線に関係しています。 （私はついに乗り越えようとしています）
ドキュメントが理解し始める前に理解するべきテキストと新しいものがたくさんあるように感じているからです。 Mavenがより広く称賛されるために必要なのは時間だけです。
なぜなら、Mavenは成長した男性を絶対的な恐怖のすすり泣くように減らすための装置だからです。
長所：
- 依存関係管理。数年前から、同僚と依存関係を手動でダウンロードして管理していません。これは非常に時間の節約になります。
- IDEに依存しません。すべての主要なIDE、Eclipse、IDEAおよびNetBeansはMavenプロジェクトを適切にサポートしているため、開発者は特定のIDEに縛られません。
- コマンドライン。 Mavenでは、同時IDEとコマンドライン構成のサポートは簡単で、継続的な統合に適しています。
短所：
- Mavenの学習に投資する必要があります。まあ、それをしなければなりません。チームの全員が学ぶ必要があるわけではありません。
- ドキュメンテーション。かつては問題でしたが、今ではSonatypeとその本のおかげで（ http://www.sonatype.com/products/maven/documentation/book-defguide ）、状況はずっと良くなっています。
- 剛性。あなたが望むように物事を行うことは時々挑戦的でイライラします。私のアドバイスは、Mavenが戦い、ベストを尽くさないようにすること、簡単なビルド、または安定したmojoがある場合です。他のケースでは、Antタスク（ http://maven.Apache.org/plugins/maven-antrun-plugin/ ）または外部プログラムのいずれかをドロップして処理します。私の個人的なお気に入りは、Groovyプラグインです（ http://groovy.codehaus.org/GMaven ）。
コンペ：
- Ant：依存関係管理はありません。期間。
- Ivy：まだMavenよりも成熟度が低い（後者にも癖がないわけではない）。ほぼ同じ機能セットなので、移動する説得力のある理由はありません。私はいくつか試してみました。すべて失敗しました。
結論：私たちのプロジェクトはすべて、数年前からMavenを使用して行われています。
私は、最もシンプルで最も複雑なプロジェクトを持っている人々からは評判が悪いと思います。
単一のコードベースから単一のWARを構築する場合、プロジェクト構造を移動し、3つのjarのうち2つをPOMファイルに手動でリストする必要があります。
5つのWARファイル、3つのEJB、17のその他のツール、依存関係のjar、および最終ビルド中に既存のリソースのXMLファイルを調整する必要がある構成を組み合わせた9つのEARファイルプロトタイプのセットから1つのEARを構築する場合; Mavenは制限が厳しすぎる可能性があります。このようなプロジェクトは、複雑なネストされたプロファイル、プロパティファイル、およびMavenビルド目標と分類子指定の誤用の混乱になります。
そのため、複雑度曲線の下部10％にいる場合は、過剰です。その曲線の上位10％で、あなたは拘束されています。
Mavenの成長は、中間の80％でうまく機能するためです。
私の経験は、ここでの多くの投稿のフラストレーションを反映しています。 Mavenの問題は、究極の自動魔法の良さを求めて、ビルド管理の詳細をラップして隠すことです。これにより、破損した場合、ほとんど無力になります。
私の経験では、mavenの問題は、ルート運河と同様の経験で、ネストされたxmlファイルのWebを介して、数時間のスナイプハントにすぐに退化しました。
また、私はMavenに大きく依存するショップで働いていましたが、Mavenを気に入った人（「ボタンを押して、すべて完了」の面で気に入った人）はそれを理解していませんでした。 Mavenビルドには100万個の自動ターゲットがありましたが、それらが何をしたかを読み通すのに何時間もかけたいと思ったら、きっと役に立つでしょう。あなたが完全に理解している、より良い2つのターゲット。
警告：2年前にMavenで最後に働いたが、今はもっと良いかもしれない。
グレンのように、私はMavenが悪い担当者を持っているとは思わないが、混合担当者はいる。私は6か月間、かなり大きなプロジェクトプロジェクトをMavenに移行することに専念してきましたが、ツールの限界を明確に示しています。
私の経験では、Mavenは以下に適しています。
- 外部依存関係管理
- ビルドの集中管理（pom継承）
- 多くのことのための多くのプラグイン
- 継続的統合ツールとの非常に優れた統合
- 非常に優れたレポート機能（FindBugs、PMD、Checkstyle、Javadocなど）
また、次の問題があります。
- all or nothingアプローチ（Mavenにゆっくり移行するのは難しい）
- 複雑な依存関係、モジュール間の依存関係
- 周期的な依存関係（デザインが悪いことは知っていますが、5年間の開発者は修正できません...）
- コヒーレンス（バージョン範囲はどこでも同じように機能しません）
- バグ（バージョン範囲も同様）
- 再現可能なビルド（すべてのプラグインのバージョン番号を修正しない限り、6か月以内に同じビルドを取得できるかどうかはわかりません）
- ドキュメントの欠如（ドキュメントは基本的には非常に優れていますが、大規模なプロジェクトを処理する方法の例は多くありません）
コンテキストを説明するために、このプロジェクトに取り組んでいる開発者は約30人であり、プロジェクトは5年以上にわたって行われています。つまり、多くのレガシー、多くのプロセスが既に配置され、多くのカスタム専用ツールが既に配置されています。プロプライエタリなツールを維持するコストが高すぎたため、Mavenへの移行を試みることにしました。
このフォーラムで寄せられた苦情のいくつかに対抗したいと思います。
Mavenはオールオアナッシングです。または、少なくともドキュメントからわかる限り。 Mavenをantのドロップイン置換として簡単に使用することはできず、徐々により高度な機能を採用できます。
これは真実ではありません。 Mavenの大きな勝利は、それを使用して合理的な方法で依存関係を管理することです。Mavenでそれを実行し、antで他のすべてを実行する場合は、できます。方法は次のとおりです。
<?xml version="1.0" encoding="UTF-8"?>
<project name="foo" basedir="." xmlns:maven="antlib:org.Apache.maven.artifact.ant" >
<maven:dependencies verbose="true" pathId="maven.classpath">
<maven:pom id="maven.pom" file="pom.xml" />
</maven:dependencies>
</project>
これで、pomファイルで定義されたすべてのmaven依存関係を含む「maven.classpath」という名前のクラスパスオブジェクトが作成されました。必要なのは、Maven antタスクjarをantのlibディレクトリに入れることだけです。
Mavenは、ビルドプロセスをネットワーク接続に依存させます。
デフォルトの依存関係とプラグインの取得プロセスはネットワーク接続に依存します、はい、ただし初期ビルドのみ（または使用中の依存関係またはプラグインを変更する場合）。その後、すべてのjarがローカルにキャッシュされます。また、ネットワーク接続を強制しない場合は、オフラインモードを使用するようにMavenに指示できます。
それは最初からあなたに堅い構造を課します。
これがファイル形式に関するものなのか、「コンベンション対構成」問題なのかは明らかではありません。後者の場合、Javaソースファイルとリソースの予想される場所、またはソースの互換性のように、多くの見えないデフォルトがあります。しかし、これはそうではありません。すべての設定は非常に簡単にオーバーライドできます（ただし、初心者にとっては、特定の変更方法をドキュメントで見つけるのは難しい場合があります）。
ファイル形式について話している場合は、次のパートへの応答で説明しています。
XMLベースであるため、ANTと同じくらい読みにくくなっています。
まず第一に、私はあなたがそれが悪い担当者を持っていることの正当化として「アリよりも良くない」何かのいくつかの側面を不平を言うことができるとは思いません。第二に、まだXMLですが、XMLの形式はmuchより定義されています。さらに、そのように定義されているため、POMの賢明なシッククライアントエディターを簡単に作成できます。私は、あちこちにジャンプするページの長いantビルドスクリプトを見てきました。 antビルドスクリプトエディターは、それをより美味しくするのではなく、わずかに異なる方法で提示される相互接続されたタスクのもう1つの長いリストです。
私がここで見たいくつかの不満があると言って、それはいくつかの有効性を持っているか、持っていました、最大の存在
- 文書が不十分/欠落している
- 再現可能なビルド
- Eclipseの統合が悪い
- 虫
私の応答は2つあります。まず、MavenはAntやMakeよりもはるかに新しいツールであるため、これらのアプリケーションの成熟レベルに到達するには時間がかかることを予想する必要があります。 2番目は、それが気に入らない場合はfix itです。そのオープンソースプロジェクトであり、それを使用して、誰もが解決に手を貸すことができる何かについて不平を言うことは、私にとっては非常に単純です。ドキュメントが好きではありませんか？初心者にわかりやすく、より完全に、またはアクセスしやすくするために貢献してください。
再現可能なビルドの問題は、バージョン範囲とmavenプラグインの自動更新という2つの問題に分類されます。プラグインの更新については、1年後にプロジェクトをリビルドするときに、まったく同じJDKとまったく同じAntバージョンを使用していることを確認していない限り、これは別の名前の同じ問題です。バージョン範囲については、すべての直接および推移的な依存関係のロックされたバージョンで一時的なpomを生成し、それをmavenリリースのライフサイクルの一部にするプラグインで作業することをお勧めします。そうすれば、リリースビルドpomsは常にすべての依存関係の正確な記述になります。
それは持っている評判に値します。 Mavenの開発者がすべてのプロジェクトに適切であると考えた堅固な構造が誰もが必要とするわけではありません。それはとても柔軟性がありません。そして、多くの人々にとっての「プロ」である依存関係管理は、私見の最大の「詐欺」です。私は、Mavenがネットワークからjarをダウンロードすることにまったく不安を感じており、非互換性のために睡眠を失います（そう、オフラインモードが存在しますが、なぜこれらの数百のxmlファイルとチェックサムが必要なのでしょうか）。使用するライブラリを決定し、多くのプロジェクトでは、ネットワーク接続に依存するビルドについて深刻な懸念を抱いています。
さらに悪いことに、物事が機能しない場合、あなたは絶対に失われます。ドキュメントはひどいです、コミュニティは無知です。
1年後、私はこれを更新したかった：Mavenコミュニティについてのこの意見はもうありません。今日質問がされた場合、私はこの答えを書きません。現在の意見を別の回答として追加します。
これは非常に主観的な答えですが、質問は意見に関するものなので、...
私はMavenが好きで、それを知るほどより気に入っています。しかし、それに対する私の感情に影響を与えているものの1つは、Mavenコミュニティの大部分がSonatype（「Maven企業」、Maven honchoの多くが活動している場所）に集中していることです。
例：「Maven Book」Twitterストリームは、想定される リポジトリ管理の紹介 にリンクしています。
申し訳ありませんが、その「イントロ」はネクサスの半分の情報、半分の売り込みです。ポップクイズ：NexusとNexus Pro以外にotherリポジトリマネージャーはいますか？また、それはおそらくオープンソースのMaven Bookと何の関係があるのでしょうか？ああ、そうですね、リポジトリ管理に関する章は、Nexusに関する別の本にまとめられています。ほらMavenブックに寄稿した場合、Nexusの売上が増加した場合、紹介料は発生しますか？
あなたがJava開発フォーラムに参加していて、Javaについて議論しているSunの従業員がNetBeansと「NetBeans Pro」：しばらくすると、コミュニティの感覚がいくらか失われます。
すべてを言ったが、Mavenはソフトウェア開発の構成とビルド管理のための非常に興味深く有用なシステムだと思います（Antのように、Mavenはそれよりも広いツールではありません）。依存関係管理は時として祝福であり呪いでもありますが、それは爽やかであり、Mavenが提供する唯一の利点ではありません。私はおそらく、Sonatypeシリングに少し強く反応しすぎていますが、私の意見では、Mavenが連想を傷つけます。この意見が他の人と共有されているかどうかはわかりません。
Mavenはプロジェクトに構造を課すので、Mavenは悪いラップになると思いますが、Antなどの他のツールを使用すると、任意の方法で構造を完全に定義できます。ドキュメントが悪いことにも同意しましたが、主にMavenが受ける悪いラップは、人々がAntに慣れているためだと思います。
満足していない人は不満を言っているのに、満足している人は満足しているとは言わないからです。私のポイントは、満足していないよりもはるかに満足しているMavenユーザーがいるが、後の方が騒がしいということです。これは、実際の生活（ISP、電話会社、交通機関など）からの一般的なパターンです。
あまりにも多くの魔法。
私のペットの中には、Mavenを使ったものがいくつかあります。
XML定義は非常に不格好で冗長です。彼らは属性について聞いたことがありませんか？
デフォルト設定では、すべての操作で常に「ネット」を検索します。これが何かに役立つかどうかに関係なく、「クリーン」のためにインターネットアクセスを必要とすることは非常に愚かに見えます。
繰り返しますが、デフォルトでは、正確なバージョン番号を指定しないと、最新バージョンが依存関係エラーを引き起こすかどうかに関係なく、最新の更新を「ネット」から取得します。言い換えれば、あなたは他の人々の依存関係管理に翻弄されています。
このすべてのネットワークアクセスの解決策は、
-oオプション。ただし、依存関係の更新を本当に行いたい場合は、忘れずにオフにしてください。別の解決策は、依存関係のために独自の「ソース管理」サーバーをインストールすることです。サプライズ：ほとんどのプロジェクトにはすでにソース管理がありますが、追加セットアップなしで機能するだけです！
Mavenビルドは非常に遅いです。ネットワークの更新をいじることでこれを緩和できますが、Mavenのビルドは依然として低速です。そして恐ろしく冗長です。
Mavenプラグイン（M2Eclipse）は、Eclipseとほとんど統合できません。 Eclipseは、バージョン管理ソフトウェアおよびAntとスムーズに統合されます。比較すると、Maven統合は非常に不格好で見苦しいです。遅いと言った？
Mavenは引き続きバグが多いです。エラーメッセージは役に立ちません。多くの開発者がこれに苦しんでいます。
私はmavenが好きです。 1.0より前から使用しています。これは強力なツールであり、バランスのとれた時間を大幅に節約し、開発インフラストラクチャを改善しました。しかし、私は一部の人々が持っている不満を理解することができます。 3種類のフラストレーションがあります。
- 原因が実際の懸念事項である場合（例：詳細なPOM、ドキュメントの欠如）、
- 一部は誤った情報です（たとえば、「構築するにはインターネット接続が必要です」-真実ではありません-しないでください、これは回避できます）、
- それのいくつかはMavenで発散されますが、実際には他の誰かが犯されます（「メッセンジャーを撃つな」）。
最初の場合、実際の問題-まあ、確かに問題があります。POMは冗長であり、ドキュメントの方が良いかもしれません。それでも、Quick TimeでMavenを使用すると良い結果を得ることができます。 antでビルドされたプロジェクトを取得するたびにうんざりし、これをIDEにインポートしようとします。ディレクトリ構造のセットアップには時間がかかる場合があります。 Mavenを使用する場合、IDEでPOMファイルを開くだけです。
2番目の場合、Mavenは複雑であり、誤解は一般的です。 Maven 3がこの複雑さ（または知覚される複雑さ）に対処する方法を見つけることができれば、それは良いことです。 mavenはかなりの投資を行いますが、私の経験では、投資はすぐに対価を支払います。
最後の点については、おそらくMavenの推移的な依存関係に関する不満が最もよく知られている例だと思います。
推移的な依存関係は、再利用を採用する実際のソフトウェアの性質です。 Windows DLL、Debianパッケージ、Javaパッケージ、OSGiバンドル、C++ヘッダーファイルにもすべて依存関係があり、依存関係の問題が発生します。2つの依存関係があり、それぞれが同じバージョンを使用している場合Mavenは依存関係の問題を解決しようとせず、むしろそれを最前線にもたらし、競合を報告し、一貫性のある依存関係を提供するなど、問題の管理に役立つツールを提供しますプロジェクトの階層。実際には、プロジェクトの依存関係を完全に制御します。
各プロジェクトに手動で依存関係を含めるアプローチ（あるポスターによると、ソース管理へのすべての依存関係をチェックする）は、依存関係の更新をチェックインせずにライブラリが更新されるときに見落とされる更新など、間違った依存関係を使用するリスクを冒しています。どんな規模のプロジェクトでも、依存関係を手動で管理すると間違いなくエラーが発生します。 Mavenを使用すると、使用するライブラリバージョンを更新でき、正しい依存関係が含まれます。変更管理では、（プロジェクト全体の）古い依存関係セットを新しいセットと比較できます。また、変更を慎重に精査し、テストすることができます。
Mavenは依存関係の問題の原因ではありませんが、よりわかりやすくなっています。依存関係の問題に取り組む際に、mavenは依存関係の「微調整」を明示的にします（依存関係をオーバーライドするPOMの変更）。バージョン管理で手動で管理されるjarの場合のように、jarは単に存在し、それらが正しい依存関係であるかどうかをサポートします。
私にとって最も重要な問題は、Mavenが適切に構成されていないと、次の理由で繰り返し可能なビルドが生成されない可能性があることです。
- 信頼性の低いリモートリポジトリ。
- sNAPSHOTバージョンまたはバージョンなしのプラグインおよびライブラリへの依存関係。
これは、すべてのjarファイルがローカルでチェックインされるため、冗長で面倒なIMOでも機能するantビルドとは対照的です。
良い点は、問題に対処できることです。
- シンプルになった独自のMavenリポジトリを使用します。私は Archiva を使用しています。
- 依存関係を常に適切にバージョン管理してください。 Mavenは、2.0.8または2.0.9から始まるスーパーPOMのプラグインバージョンのロックダウンを開始し、すべての依存関係はリリースバージョンにあるはずです。
素晴らしいアイデア-不十分な実装。
最近、プロジェクトをAntからMavenに移動しました。最後にうまくいきましたが、同じpomで2つの異なるバージョンのmaven-Assembly-pluginとmaven-jar-pluginを使用する必要がありました（2つのプロファイルを取得しました）。
それでかなり頭痛がしました。ドキュメントは常に素晴らしいとは限りませんが、答えをグーグルで検索するのは比較的簡単だったことを認めなければなりません。
使用するプラグのバージョンを常に指定するようにしてください。新しいバージョンに後方互換性があるとは思わないでください。
論争は、メイヴンがまだ進化しており、プロセスが時々苦痛であるという事実から来ていると思います。
よろしく
v。
人々がMavenを好まない理由はたくさんありますが、それらに直面してみましょう非常に主観的。優れた（そして無料の）本、より良いドキュメンテーション、より大きなプラグインのセット、多くの参照成功プロジェクトビルドを備えた今日のMavenは、1、2年前と同じMavenではありません。
単純なプロジェクトでMavenを使用するのは非常に簡単です。より大規模で複雑なプロジェクトでは、Mavenの哲学についての知識と理解を深める必要があります。 Mavenが嫌いな声明の主な情報源は、多くの場合ignoranceです。
Mavenのもう1つの問題は、たとえばAntで。しかし、覚えているMavenには一連の規則があります。それらに固執することは、最初は難しいように見えますが、最終的には問題から救うことがよくあります。
現在のMavenの成功は、その価値を証明しています。もちろん、完璧な人はいませんし、Mavenにはいくつかの短所とその癖がありますが、私の意見では、Mavenはゆっくりと相手を揺らします。
私はMavenが大好きです。生産性が向上し、Antを使用しなくなったことをとてもうれしく思っています（phew！）
しかし、私が物事を変えることができれば、それは次のようになります：
pom.xml冗長性の少ないファイル- リポジトリからではなく.jarを簡単に含めることができます。
良い質問。私は仕事で大規模なプロジェクトを始めたばかりで、以前のプロジェクトの一部はコードベースにモジュール性を導入することでした。
Mavenについて悪いことを聞いたことがあります。実際、それについて聞いたことがすべてです。私が現在経験している依存関係の悪夢を解決するためにそれを紹介することを見ました。 Mavenで見た問題は、Mavenの構造が非常に硬いことです。つまり、Mavenが機能するためには、プロジェクトのレイアウトに準拠する必要があります。
私はほとんどの人が言うことを知っています-あなたは構造に準拠する必要はありません。確かにそれは事実ですが、最初の学習曲線を超えて、すべての時間を費やして捨ててしまうまで、これを知ることはできません。
Antは最近よく使われていますが、大好きです。それを考慮して、私は Apache Ivy と呼ばれるあまり知られていない依存関係マネージャーに出会いました。 IvyはAntに非常にうまく統合され、基本的なJAR検索のセットアップと動作をすばやく簡単に取得できます。 Ivyのもう1つの利点は、非常に強力でありながら非常に透過的であることです。 scpやsshなどのメカニズムを使用してビルドを簡単に転送できます。ファイルシステムまたはリモートリポジトリに対する「チェーン」依存関係の取得（Mavenリポジトリの互換性は人気のある機能の1つです）。
結局のところ、使用するのは非常にイライラすることがわかりました-ドキュメントはたくさんありますが、悪い英語で書かれているため、デバッグや問題を解決しようとするとイライラする可能性があります。
このプロジェクトのある時点で、Apache Ivyを再訪します。ApacheIvyが適切に機能することを期待しています。それがしたことの1つは、チームとして、どのライブラリに依存しているかを調べ、文書化されたリストを取得できるようにすることでした。
最終的には、個人（チーム）としてyouがどのように機能するか、依存関係の問題を解決するために何youが必要かがすべてだと思います。
Ivyに関連する次のリソースが役立つ場合があります。
プロジェクトの作成に使用した言語よりも複雑です。正しく構成することは、実際のプログラミングよりも困難です。
簡単な答え：Mavenビルドシステムを維持するのは非常に難しいことがわかりました。できるだけ早くGradleに切り替えたいと思います。
私はMavenで4年以上働いています。私は自分自身をビルドシステムの専門家と呼んでいます。なぜなら、過去（少なくとも）5つの会社で、ビルド/デプロイインフラストラクチャの大規模な改修を行ったからです。
私が学んだ教訓のいくつか：
- ほとんどの開発者は、システムの構築について考えるのに多くの時間を費やさない傾向があります。その結果、ビルドはスパゲッティのハックの混乱に変わりますが、その混乱がクリーンアップされ、合理化されると感謝します。
- 複雑さを扱う際には、Mavenのような厳格な制限を課すことによって複雑なものを単純にしようとするシステムよりも、複雑なものを公開する透過的なシステム（Antなど）が必要です。 LinuxとWindowsを考えてください。
- Mavenには、ビザンチンの回避策を必要とする機能に多くの穴があります。これにより、POMファイルが理解不能で保守不能になります。
- Antは非常に柔軟で理解しやすいですが、Antファイルは非常に低レベルであるため、かなり大きくなる可能性があります。
- 重要なプロジェクトの場合、開発者はツールが提供する以上の独自のビルド/デプロイ構造を作成する必要があります。プロジェクトへの構造の適合性は、維持するのがいかに簡単であるかに大きく関係しています。最高のツールは、あなたと戦うのではなく、構造の作成をサポートします。
私はGradleを少し調べましたが、両方の世界で最高になる可能性があり、宣言的なビルド記述と手続き的なビルド記述を混在させることができます。
私にとって、社内プロジェクトでmaven vs antを使用することには短所と同じくらいの長所があります。しかし、オープンソースプロジェクトの場合、Mavenは多くのプロジェクトの構築をはるかに簡単にすることに大きな影響を与えたと思います。コンパイルに平均OSS Java（antベース））プロジェクトを取得したり、大量の変数を設定したり、依存プロジェクトをダウンロードしたりするのに数時間かかりました。
AntでできることはMavenで何でもできますが、Antが標準を推奨していない場合、Mavenはその構造に従うことを強くお勧めします。そうしないと、さらに作業が必要になります。確かに、Mavenで設定するのは簡単で、Antで簡単にできるものもありますが、最終結果は、ほとんどの場合、プロジェクトをチェックアウトしたい人の観点から構築しやすいものです。
開発プロジェクトにビジネスや仕事を賭けようとするなら、基盤、つまりビルドシステムを管理したいと思うでしょう。 Mavenを使用すると、制御できません。宣言的で不透明です。 Mavenフレームワークの開発者には、透過的または直感的なシステムの構築方法がわかりません。これは、ログ出力とドキュメントから明らかです。
依存関係管理は非常に魅力的です。なぜなら、プロジェクトの開始時にある程度は同じかもしれませんが、警告されます。根本的に壊れており、最終的には多くの頭痛の種になります。 2つの依存関係に互換性のない一時的な依存関係がある場合、チーム全体のビルドを中断し、数日間開発をブロックするラットの複雑な巣によってブロックされます。 Mavenを使用したビルドプロセスは、ローカルリポジトリの状態が一貫していないため、チーム内のさまざまな開発者にとって一貫性がないことでも有名です。開発者が環境を作成した時期、または作業している他のプロジェクトに応じて、結果は異なります。ローカルリポジトリ全体を削除し、devブランチの初回セットアップよりもはるかに頻繁にMavenでjarを再ダウンロードしていることがわかります。 OSGIは、この根本的な問題を解決しようとしているイニシアチブだと思います。多分何かがとても複雑である必要があるなら、基本的な前提は間違っていると言うでしょう。
私は5年以上にわたってMavenのユーザー/被害者であり、ソースリポジトリへの依存関係をチェックし、ニースでシンプルなantタスクを記述するだけでなく、はるかに時間を節約できると言わざるを得ません。 antを使用すると、ビルドシステムが実行していることを正確に把握できます。
私は、Mavenの問題のために、いくつかの異なる会社で多くの人を失い、多くの時間を失いました。
私は最近、古いGWT/Maven/Eclipseプロジェクトを復活させようとしましたが、2週間後に余暇を過ごしましたが、一貫してビルドすることはできません。それは私の損失を削減し、ant/Eclipseを使用して開発するときです...
担当者が混在するほど悪い担当者だとは言いません。プロジェクトがMavenが提唱する「設定より規約」のパラダイムに従っている場合、そのプロジェクトから多くのレバレッジを得ることができます。プロジェクトがMavenの世界観にうまく適合しない場合、負担になる可能性があります。
そのために、プロジェクトを制御できる場合は、Mavenが最適な方法です。しかし、もしそうでなく、レイアウトがMavenのファンではない誰かによって決定されている場合、それは価値があるよりももっと面倒かもしれません。最も幸せなMavenプロジェクトは、おそらくMavenプロジェクトとして開始されたプロジェクトです。
ここで言及したほとんど/すべてのネガティブ、およびチームメイトからの同様の反対意見に苦労し、それらすべてに同意します。しかし、私はそれを固守しており、maven（またはおそらくgradle）のみが実際に提供する1つの目標に固執することで、これを続けます。
ピア向けに最適化する場合（オープンソースdevelopers）、ant/make/whateverが実行します。非ピアに機能を提供している場合（sers）、maven/gradle/etcのみが行います。
IDEによってロードできる十分に文書化された標準プロジェクトレイアウトで、ソースコード+ pomsの小さなバンドル（暗号化された名前と依存関係情報のない埋め込みlib /バイナリ依存関係jarなし）をリリースできるのはmavenのみです。開発者の特異なレイアウト規則を吸収していない人。また、不足している依存関係を取得しながらすべてをビルドするワンボタンインストール手順（mvn install）があります。
その結果、ユーザーはコードに簡単に辿り着くことができ、pomsは関連するドキュメントを指すことができます。
その（必須の）要件とは別に、私は誰よりもMavenを嫌います。
任意のJava開発者は簡単にANTエキスパートになることができますが、エキスパートでもないJava開発者はMAVEN初心者レベルになることはできません。
Mavenを使用すると、開発者はBuild and Deploymentに関連するすべてのことを怖がらないようになります。
彼らはWarファイルやEarファイルよりもMavenを尊重し始めます!!悪い悪い悪い！
その後、あなたはオンラインフォーラムに翻弄され、ファンボーイは「Mavenのやり方」を行わないことであなたを非難します。
私はMaven 1と2を区別したいと思います：前者は（当然）悪い評判を持っています。後者は改善であり、上昇する「標準」です。
私個人の意見では、Maven 2は私が好むよりも複雑で硬直しています。ある男性の標準は、別の男性のストレートジャケットです。上記の「マジックが多すぎる」というコメントに同意します。 AntのシンプルさとMaven 2の複雑さを比較すると、どちらが好みかわかります。
私は、Antをはるかによく知っていることを認めます。私はMaven 2を探している最中ですが、まだそこまで進んでいません。私の貧弱な意見は、Maven 2の真の価値について言うよりも、私と私の知識の状態についてもっと言うかもしれません。
評判が悪い主な理由の1つは、maven2がいくつかの複雑な問題（ビルドの自動化、依存関係、リポジトリの管理）をワンショットソリューションとして解決したことだと思います。そのため、Mavenの使用を開始するときにこれらの困難な問題に直面する必要があります。したがって、これは一種の「メッセンジャーを殺す」効果です。
他のアプローチ（例：ant + ivy）では、発生するすべての問題を1つのツールで責めることはできません。 「始めるのは本当に簡単じゃないけど、アイビーにはいくつかの問題があります。でも、少なくとも私たちはMavenに取り組む必要はありません！」に似ています。これらすべての問題をまとめて、mavenを使用するときに遭遇する問題とあまり異ならないことを認識していないと言います。一度に1つずつ取り組む方が少し簡単かもしれません。ところで、私は過去数ヶ月でant + ivyに基づいたビルドシステムをセットアップしました。そして、maven2を使用する必要がなかったのは本当に嬉しいです;-)
私の答え：ほとんどのユーザーは、Mavenの長所を探しているため不満を言っていますが、「会社の環境」を設定する時間がない（または耐えたくない）のです。それは個人的な選択であり、個人的な忍耐、仕事環境（上手くやっていることは永遠のバグ修正サイクルよりも時間を無駄にしないことを上司は決して理解しません）などに依存します。
ただし、次の場合は、ワークステーション上でMavenのみを使用できます。
- いくつかのBeanを含むシンプルなライブラリ。
- 単純な「オールインワン」戦争。
- 「標準」依存関係（スプリング、休止状態、Apacheの内容、および中央リポジトリで見つけることができるもの）があるマルチモジュールプロジェクトでもただし、ライブラリに依存関係はありません。
標準フレームワーククラスや再利用可能なコンポーネントライブラリへのラッパーを作成したり、好きなプラグインのセットを常に使用したいなど、必要なときに問題が発生し始めます。
その場合学習に時間を費やす必要があります：私は誰かが半日または2日の無駄遣いについて話していることを以前の投稿で読みました...それだけでは十分ではありません：変更について話している少なくとも1か月間、pomsを継続的に使用します。
複雑なプロジェクトでMavenを使用する場合は、次の順序で行う必要があります。
- 内部リポジトリがあります。これはオプションではなく、必須です。 ArtifactoryとNexusを試したところ、最初はトラブルが発生する可能性がありますが、一度セットアップすると忘れてしまいます。
- 必要なすべてのプラグイン（指定された相対バージョン）を含む「マスターpom」を作成しますが、問題にならない場合は、標準の依存関係を置かないようにする必要があります（そのため、 dependenciesManagementのscope = import）。これは最も難しい部分ですが、有名なプロジェクト（春、タペストリー、ecc ...）のマスターポンをコピーして、必要のないものを取り除くことができます。
- 複雑なプロジェクトがある場合は、アーティファクトの作成を開始する前に、自分が望むものを考える必要があります。たとえば、（war + WebServices Client）+（Webservice Server + spring + hibernate + Jbpm + whateverelse ....）を持つプロジェクトでは、両方のクライアントによって参照される「api」モジュールを作成することをお勧めしますサーバー。ただし、モデルとインターフェイスのみが含まれ、クライアント側とその反対側に「サーバー側」の依存関係はありません。 それに失敗すると、Mavenは地球上の生き地獄になります。
- eclipseを使用する場合、m2eプラグインが不可欠です。OK、遅い場合があります。プロジェクトを更新し、プロジェクト構成などを更新する必要がある場合があります。そして最悪の場合、コマンドラインは常に機能します。
- 継続的インテグレーションサーバーはオプションですが、少なくとも一般的なライブラリには強くお勧めします。 WebアプリケーションをCIに配置するのは多すぎる場合があります（複数のプロジェクトでWebアプリケーションを再利用しないでください）が、CIに標準の基本クラス、「常に使用される」エンティティBeanなどを配置することは貴重です。これらのコンポーネントは自分だけで使用されるわけではありませんが、コードの他の部分で忙しいときにチームメイトでも使用でき、会社のリポジトリに手動でデプロイして忘れることができることを覚えておいてくださいチームメンバーが利用できます。
これらすべてをセットアップするために...まあ、最初は数か月も費やすことができますが、慣れると、開発が大幅にスピードアップします。
個人的にはGradleをまだ使用していません。Mavenよりも優れているか最悪かはわかりません。
Mavenのラップが悪い最大の理由はIDE統合です。はい、m2Eclipseについて知っています。m2Eclipseが好きです。Netbeansの統合がさらに好きです。
ここに問題があります。いくつかの大規模なショップでは、MavenをRAD 7.0などのように動作させるためのツールを作成しました。うまく動作しません。これらのハックアラウンドは、許可されていないツール内で（RAD 7.0）。私の場合、ハックアラウンドされたMavenビルドはNetbeans内でのみ動作しますm2Eclipseを備えたEclipse 3.5は恐ろしい何かを窒息させます。
ここのほとんどの開発者はMavenを嫌っています。彼らはMavenを嫌いではありません。 実際に Mavenを使用したことはありません。
期待はずれですが、実際にはMavenのせいではありません。 Mavenは私にとって、別の人生でうまく機能しました。ここでは、IDEと、それを使用可能にするためのツールが失敗するため、衰弱しています。
Mavenのディフェンダーは「よく、あなたはそれを理解していないだけだ」と言うのが一般的です。彼らは、これは本当に気の利いた繰り返しだと考えています。
こんなふうになります：
スーパープログラマー：「ねえ、このドアを開いたままにする必要があります、誰でもドアストップを持っていますか？」ドアが開いた！」 Mavenプログラマー（スマグ、くすくす笑う）：「あなたはそれを理解していないだけです。マニュアルを読んで、約1年間本当に勉強することをお勧めします!!!」
ここでの私の考えは、構成に関する慣習の落とし穴に基づいています。
http://chriswongdevblog.blogspot.com/2011/01/trouble-with-being-conventional.html
Mavenでの私の問題は、発見の困難さと無限の複雑さです。それと、同僚がMavenビルドの問題と戦う1日の半日を無駄にしているのを見ています。また、私見では、MavenとEclipseの統合により事態が悪化しています。
わかりました。Mavenの詳細を詳しく知ることはできませんが、認めようとするよりも何度も機能させようとしました。
私にとってMavenの使用は非常に簡単です。
。あなたはアリのためにしない特別なMavenの第一人者を「雇う」必要があります。そうでない場合は、開発者に、作業を「行う」方法に頼るのではなく、作業を「構築する」方法の学習に時間を費やすよう依頼します。
。あなたが本当にそれを理解したいなら、あなたは本を売る必要があります。
その後：
。基本的には「依存関係」という本当の問題を1つだけ解決しますそして、ANTはそれを行うことができませんか？
。個人的には、オープンソースフレームワークの新しいバージョンにアップグレードする必要はありませんが、盲目的にアップグレードすることはありません。動作している場合は、修正しないでください。
しかし、これは主観的です正しいですか？
Mavenは、生産性を高めることができるソフトウェア管理ツールです。このようなツールは、新しい時代のソフトウェア開発に不可欠だと思います。
ただし、Mavenはすべてのコードベースに適しているわけではありません。大きなレガシコードページをサポートする必要がある場合、またはサードパーティからコードをインポートする場合は、使用を避けることをお勧めします。 Mavenは、物事が特定の方法（構成よりも慣習的）であることを期待しています。新しいプロジェクトを開始する場合は、これで十分です。ただし、サポートする必要がある完全なシステムがある場合、柔軟性の欠如は悪夢です。
人々が通常mavenについて不平を言う別の理由は、急な学習曲線です。またIDE統合はまだそれほど成熟していません。 Apache はEclipse用の2つのプラグインを提供しています。最初のものが適切であれば、新しいものは必要ないと思います。
別の、より深刻なMavenについての不満は、プログラミング作業を行うためのXMLの使用です。おそらく Buildr のようなツールが最適です。
既に述べた「オールオアナッシング」アプローチは、私が通常代わりにAntを使用する理由でした...はるかに多くの場合、変更できない定義済みの構造をすでに持っている「レガシー」プロジェクトで作業するようになりますMavenがそれ以外のことを望んでいるからです。
一方、Antは、プロジェクトの混乱に関係なく、いつでも使用できます。
代替案に関して、私はレーキについて良いことを読みました。
（ところで、私はMaven 1について話しているのですが、まだMaven 2を調べていません）
非常に単純に、Mavenは世界を所有したいと考えています。プロジェクト、ファイルシステム上でのレイアウト、jarがキュートなローカルキャッシュに配置される場所、物を取得する方法、依存関係グラフ、プラグインを構築する、ideプラグインなどを定義する必要があります。
一部の人々はそのようなことを愛し、賞賛します。私にとって、それはすべて品質に関するものであり、あなたのboooooring理論についてはあまり気にしません。ただ実行し、問題なく実行し、できれば背景にフェードインして、もう一度あなたと混乱することを決めます。
SonatypeとMavenの支持者/謝罪者への私のメッセージは、あなたはまだ品質にじみ出ていないということです。 pom.xml形式は冗長でアカデミックで退屈です。修正してください。複雑なマルチプロジェクトビルドは、Mavenを使用したセットアップに腹を立てています-なぜそんなに難しいのですか？指定されたjarを取得するタイミングと取得しないタイミングを微調整することは興味深いことです-それが得られるまで、私たちができる/考えたいときはいつでも取得するMaven戦略は気が狂います。 SNAPSHOTは、私を叫んで/笑って、私を怒らせているので、常にすべてキャップです。オープンソースのmavenプラグインがpomsにプラグインされるという、汚い方法とグーフィー/ユニークな方法は気が遠くなります。それらを解決する良い方法がないクラスパスの問題？そうそう、レガシのApache commons- * groupIdがリポジトリのルートを汚染していることは、「チーズの三角形はそんなふうに行かない!!」と怒り狂っています。 m2Eclipseは純粋に集中した狂気であり、モンスターは死に、火でそれを殺します。それが私たちが確信できる唯一の方法です。
Mavenはクライアントに一度私を当惑させました-ツールが私の生産性の邪魔になったことは許されません！私は自分のツール（およびそのメーカー）が謙虚な使用人のように振る舞うことを望んでいます。王が誰であるかをMavenに尋ねると、答えは「DAVE」であり、その後に快楽と多くのお辞儀と低音が続くことを期待しています！ :)
慣性はMavenの本当の物語です。もしあなたがオープンソースのJavaで遊びたいなら、あなたはほとんどMavenリポジトリからプルするでしょう。ニースをそこでプレイしたい場合は、Mavenの方法で依存関係を取得し、pomsを読むことができるようにした方がいいでしょう... IvyとIvyDEに感謝します。 Mavenツールチェーンにとらわれないでください。
NexusやArtifactoryのように私が使用したMavenリポジトリサーバーソフトウェアは、きちんとした未来的なツールです。彼らは他のMavenエコシステムと比較してきらびやかな宝石です。
私のMavenの経験は、Eclipseが当時どのように感じていたかのようです。 Eclipseは彼らの馬鹿げたアイデアで世界も所有したかったのですが、Eclipseが自分の世界を所有できるようになるまで、プラットフォームが成熟するまでに長い時間がかかりました。おそらく、Mavenはそのレベルの品質に達することができますか？この時点で、私は「二度と目が恐怖を目撃することはない」と言いますが、Eclipse 1.0についてもそれが出てきたときに言っていました。 :)
Mavenは作業上の問題を解決し、Javaソフトウェアと簡単な依存関係管理を構築します。ただし、Antとは大きく異なり、GNU Make、または他のUnix-パッケージ管理システムのように、これは新人がそれを学ぶために多くを払わなければなりません。
多くのMavenドキュメントがありますが、それらのいくつかpushing「m2Eclipseの使用」のように」：
groupIdをクエリフィールドに入力するだけで、m2Eclipseはリポジトリインデックスをクエリし、現在ローカルMavenリポジトリにあるアーティファクトのバージョンも表示します。このオプションは、非常に時間を節約できるため、推奨されます。
長い文章を理解するのは本当に嫌いで、何も言わないことがわかりました。 python公式チュートリアルとアーランのチュートリアルを読んだときの気持ちの良さを思い出すことができます。良いドキュメントは、著者が良い感覚を持っていることを示しています。
Mavenは初心者には奇妙に見えますが、コマンドラインのスタイルはUnixコマンドラインの伝統とは異なります。あなたが「例によるMaven」または「決定的なガイド」を通過する時間を払えば、それは報われます、あなたはそれを見つけることができます http://www.sonatype.com/ 。しかし、これらのドキュメントをすべて読み、自信を持ってツールを使用できる場合でも、ソフトウェアのバグが原因でトラブルが発生することがあります。そして、専門家はそれとともに生き、生産性を維持する方法を得ます。
結局のところ、Mavenはオープンソースソフトウェアであり、フリーエンジニアに知識を提供します。そして、これはそれを尊重します。人々がそれについて悪い評判について話すとき、それは良い仕事をしているオープンソースの世界。
したがって、熟練した人々がツールを使用する方法として、それを使用し、それに依存しないでください。あなた自身に依存します。
Mavenは非標準操作を簡単にサポートしません。有用なプラグインの数は常に増加しています。 MavenもAntも、Makeのファイル依存関係の概念を簡単/本質的にサポートしていません。
利点：
Mavenは、すぐに起動して実行する必要があり、依存関係管理が優れている場合に最適です。 jar-hellを回避する機能も悪くありません。 Mavenの背後にある基礎理論のいくつかは健全です。デフォルトのライフサイクルフェーズはよく考えられており、ビルドエンジニアリングのベストプラクティスを学びたい人にとって非常に有益です。不十分なドキュメンテーションにもかかわらず、発見可能性は優れています。mvnhelp：help -Ddetail = trueを試して、意味を確認してください。 xsdドキュメントの読み方を知っていれば、pomの構築はそれほど難しくありません。
短所（悪魔は詳細にあります）：
同じフェーズにバインドされているさまざまなプラグイン実行の順序を指定することはできません。また、コンピュータープログラミングにおける非決定性の形式は、まったくひどいものです。
Antプロパティ値（例：$ {my.property}）とは異なり、Mavenプロパティはビルドの開始時に解決されます。開始時に値が何であるかがわかっていても、プロパティの値が途中で決定される場合は問題ありませんビルドのアクセスには遅すぎます。割り当てられる前に既に解釈されているため、値はnullまたは空の文字列になります。これは、プロパティを必要とする実行が、プロパティを割り当てる実行の後のフェーズで実行される場合でさえあります->この上で髪を引き裂きます。
「Maven way」に固執すれば、すべてがスムーズに実行されます。ビルドが "Mavenの方法"から逸脱するとすぐにすべてが地獄に落ちます->オーダーメイドのMavenプラグインとアーキタイプのプログラミングがプロジェクトで非常にうまくなると期待してください。
集約（Maven-speakのモジュール）と継承（Maven-speakの親）を使用して多くのpomファイルを含む大規模なプロジェクトで作業する場合、同じまたは類似したことを行うビルド間で重複が多すぎます。 Maven xml文法では、親から継承されるメンバーとそうでないメンバーを区別する明確な方法は提供されません。実行されると予想されるmvn help:effective-pomこれを把握するために2分ごとに。
多くのプラグイン構成を持つ複雑なビルドは、肥大化してわかりにくくなります。これは、Maven自体よりもxmlの問題です。より明確で表現力豊かなビルドの記述方法があります->メタプログラミングをサポートする動的言語での内部DSLなど、Gradle、Buildr
プロファイル：大きな力には大きな責任が伴います。ビルド自体の内部のそれぞれのデプロイメント環境に属する構成を固執するのは簡単すぎるため、「1バイナリ」の原則に違反します。プロファイルは、環境ではなく「役割」を強調するように設計する必要があります。つまり、ステージング自体の構成を保持するのではなく、CIからステージングに展開する行為です。
Mavenはクールです。
現時点では、おもちゃはありません。
Microsoft開発ツールチェーンとは別に、それはお金では買えない最高のテクノロジーです。
「toolchain du jour」をプッシュしようとしているこれらのグループはすべて、混乱を招き市場シェアを獲得しようとする安価な試みです。
嫌いは嫌いです。
- SBT
地球史上最大の誤称。ビルドはチューリングテストに合格できますか？馬鹿げた、10年前の馬鹿げたDSLの時代。 Mavenの中間兄弟であるIVY依存関係管理を使用します。
- 蟻
Shockwave開発を卒業した最初のプロジェクトに最適です。
あなたはXMLを理解し、熱心ですが、ビルドフェーズを本当に理解していないので、6か月後にプロジェクトを再開します。バージョン管理バイナリアーティファクトが偽の万能薬である理由、または自分以外の誰かがいつかあなたのプロジェクトで仕事をしようとする理由です。
- MAKE
全世界が同じUNIXターミナルで実行され、流BなBashを話すのであれば、そうです。しかし、なぜC/C++プログラマーにならないのか、Javaよりもずっと楽しい。
- ルビー（さまざま）
なんでも。ニッチ、遅い。 Rubyその後、Java development。
- Python
人々はJava信頼していない場所Python（お金が関係する場所）。システムが実行されている場合Pythonとにかく、もちろんJavaお金-が必要ですが、開発中PythonいくつかのWebショップで。
- Clojure（さまざま）
ストールマンに敬意を表して、私はLISPを学びますが、Emacsについては、VMで実行するためではありません。体験が安くなると感じています。
Mavenは [〜＃〜] kiss [〜＃〜] 原則を尊重しません。 mvn clean install以外のことをしようとすると、問題が発生します。アリを使えば、苦労することなく何でもできます。
すべてのプロジェクトでmaven2を使用し、開発を10倍高速化します（Niceの継続的インテグレーションプラットフォームと組み合わせて）。
過去に多くの頭痛の種となったmaven2の唯一の機能は、推移的な依存性メカニズムです。ユートピアの世界では、すべての依存関係の問題に対する最終的な解決策になりますが、実際には、依存関係の地獄に直行する傾向があります。
私たちの主な問題は、デフォルトのmaven2リポジトリ内のさまざまなコンポーネントが同じライブラリの異なるバージョンに依存するという事実から生じました（つまり、component1とcomponent2は両方ともロギングフレームワークを必要としますが、component1はv1を必要とし、component2はv2を必要とします）。
これを解決するには、必要なすべてのライブラリを含む独自のローカルリポジトリを用意するだけです。これにより、独自の依存関係を持つ使用するすべてのライブラリが、他のライブラリの同じバージョンに依存することを保証できます。