なぜMavenはそのような悪い担当者を持っているのですか？[閉まっている]

Mavenがどのように悪いのかについては、インターネット上で多くの話題があります。私はここ数年Mavenのいくつかの機能を使用しており、私の考えで最も重要な利点は依存関係の管理です。

Mavenのドキュメントは十分ではありませんが、一般的に私が何かを達成する必要がある場合は、一度理解してから機能します（たとえば、jarへの署名を実装した場合）。Mavenは素晴らしいとは思いませんが、それがなければ本当の苦痛になるいくつかの問題を解決します。

では、なぜMavenはこのような悪い担当者を抱えているのでしょうか？また、Mavenで今後どのような問題が予想されますか？多分私が知らないはるかに良い代替案がありますか？（例えば、私はIvyを詳細に見たことがありません。）

注：これは、引数を引き起こす試みではありません。これはFUDをクリアするための試みです。

約6か月前にmavenを調べました。私たちは新しいプロジェクトを開始しており、サポートするレガシーはありませんでした。それは言った：

• Mavenはオール・オア・ナッシングです。または、少なくともドキュメントからわかる範囲で。Mavenをantのドロップイン代替として簡単に使用することはできず、徐々により高度な機能を採用することができます。
• ドキュメンテーションによると、Mavenはあなたのすべての野生の夢を実現させる超越的な幸福です。啓発される前に、マニュアルで10年間瞑想する必要があります。
• Mavenは、ビルドプロセスをネットワーク接続に依存させます。
• Mavenには役に立たないエラーメッセージがあります。antの「ターゲットxがプロジェクトyに存在しない」とmvnの「無効なタスク 'run'を比較します。有効なライフサイクルフェーズを指定するか、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はこれをうまく処理します。アリの方がずっと難しいです。
• 標準化された成果物管理（特にネクサスまたは成果物と組み合わせて）
• リリースプラグインは素晴らしいです。
• EclipseとNetBeansの統合は非常に優れています。
• ハドソンとの統合は素晴らしいです。特に、findbugsなどのトレンドグラフ。
• これはマイナーなポイントですが、Maven がデフォルトでjarまたはwar（ファイル名だけでなく）内のバージョン番号などの詳細を埋め込むという事実は、非常に役立ちます。

私の欠点は主に次のとおりです。

• コマンドラインは全く役に立ちません。これは私をそもそも先送りにしました。
• XML形式は非常に冗長です。なぜそのように行われたのかはわかりますが、それでも読むのは大変です。
  • つまり、IDEで簡単に編集できるXSDがあります。
• 最初は頭を丸めるのは難しい。たとえば、ライフサイクルのようなもの。
  • ただし、Mavenの決定的なガイドは良い入門書です。

Mavenを知るのに少し時間をかける価値があると私は本当に信じています。

2つの大きなプロジェクトでの私の実際的な経験は、Maven 1からMaven 2に移動するための500時間の労力を除いて、Maven関連の問題にプロジェクトごとに1000〜1500時間費やしたということです。

それ以来、私は絶対にmavenを憎むと言わなければなりません。それについて考えると、私は苛立ちます。

Eclipse統合はひどいです。（たとえば、Eclipseが生成されたコードと同期しなくなり、完全な再構築が必要になることがよくあるなど、コード生成に無限の問題がありました。非難はmavenとeclipseの両方ですが、ecveneはmavenやemacsよりも便利なので、日食の滞在とメイブンは行かなければならない。）

多くの依存関係があり、発見したように、構文エラーは実際には頻繁に公開Mavenリポジトリーにコミットされ、貴重な時間を何時間も損なう可能性があります。毎週。回避策は、プロキシまたはローカルで管理されるリポジトリを使用することであり、それを正しく行うのにもかなりの時間がかかりました。

Mavensプロジェクトの構造はEclipseでの開発には実際には適しておらず、Eclipseでのビルド時間は長くなります。

コード生成と同期の問題の影響で、スクラッチから再構築を頻繁に行う必要があり、コード/コンパイル/テストサイクルを無限のコンパイル/ websurf / sleep / die / code-cycleに減らし、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が利用できる場合に、Mavenと戦ったりしないようにすることです。他のケースでは、Antタスク（http://maven.apache.org/plugins/maven-antrun-plugin/）または外部プログラムのいずれかを使用せずにドロップします。私の個人的なお気に入りはGroovyプラグイン（http://groovy.codehaus.org/GMaven）です。

コンペ：

• Ant：依存関係の管理はありません。限目。
• Ivy：まだMavenほど成熟していない（後者には奇妙な点もないのではない）。ほぼ同じ機能セットなので、移動する理由はありません。私は何度か試してみました。すべて失敗。

結論：私たちのプロジェクトはすべて、数年前からMavenで行われています。

最も単純で最も複雑なプロジェクトを持っている人たちには評判が悪いと思います。

単一のコードベースから単一のWARを構築している場合、プロジェクト構造を移動し、3つのjarファイルのうち2つを手動でPOMファイルにリストする必要があります。

9つのEARファイルプロトタイプのセットから1つのEARを構築する場合、5つのWARファイル、3つのEJBとその他の17のツール、依存関係のjarファイル、および最終ビルド中に既存のリソースのMANIFEST.MFおよびXMLファイルを微調整する必要のある構成を組み合わせます。その後、Mavenは制限が厳しすぎる可能性があります。そのようなプロジェクトは、複雑なネストされたプロファイル、プロパティファイル、およびMavenビルド目標と分類子指定の誤用の混乱になります。

したがって、複雑度曲線の下位10％にいる場合は、やりすぎです。その曲線の上位10％では、拘束されています。

Mavenの成長は、80％の真ん中でうまく機能するためです。

私の経験は、ここにある多くの投稿への不満を反映しています。Mavenの問題は、究極の自動魔法の良さを求めてビルド管理の詳細をラップして非表示にすることです。これにより、壊れた場合にほとんど無力になります。

私の経験では、根管に似た経験で、mavenの問題は、ネストされたxmlファイルのウェブを介して数時間のスナイプ狩りにすぐに縮退しました。

私はMavenに大きく依存しているショップでも働いていました。Mavenを気に入った人（「ボタンを押すだけですべてを終わらせる」という面で気に入った人）は理解しませんでした。Mavenビルドには100万個の自動ターゲットがあり、何時間もかけてそれらが何をしたのかを読むのが好きだと感じた場合、私はそれが役立つと確信しています。あなたが完全に理解している、より効果的な2つのターゲット。

注意：2年前にMavenで最後に動作しましたが、今はもっと良いかもしれません。

グレンのように、Mavenは悪い担当者ではないと思いますが、混合担当者です。私は6か月間、かなり大きなプロジェクトプロジェクトをMavenに移行しようと専念してきましたが、ツールの限界を明確に示しています。

私の経験では、Mavenは次の場合に適しています。

• 外部依存関係管理
• ビルドの集中管理（pom継承）
• 多くのことのための多くのプラグイン
• 継続的インテグレーションツールとの非常に優れた統合
• 非常に優れたレポート機能（FindBugs、PMD、Checkstyle、Javadocなど）

そしてそれはいくつかの問題があります：

• オールオアナッシングアプローチ（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のフォーマットははるかに定義されています。さらに、そのように定義されているため、POM用の分厚いクライアントエディターを作成するのははるかに簡単です。あちこち飛び回る長いアリビルドスクリプトのページを見たことがあります。antビルドスクリプトエディターは、これを口当たりの良いものにするつもりはありません。わずかに異なる方法で提示された相互接続されたタスクの別の長いリストです。

ここで私が見たいくつかの不満があるか、またはある不満があると言いましたが、最大のものは

• ドキュメントが不十分/不足している
• 再現可能なビルド
• Eclipseの統合が悪い
• バグ

私の回答は2つあります。まず、MavenはAntまたはMakeよりもはるかに新しいツールであるため、これらのアプリケーションの成熟度レベルに到達するには時間がかかると予想する必要があります。2つ目は、それが気に入らない場合は修正することです。オープンソースプロジェクトであり、それを使用してから、だれでも解決できる何かについて不平を言うのは、私にはかなりおかしいようです。ドキュメントが気に入らない？初心者がより明確に、より完全に、またはよりアクセシブルになるように貢献してください。

再現可能なビルドの問題は、バージョン範囲とMavenプラグインの自動更新という2つの問題に分類されます。プラグインの更新については、1年後にプロジェクトを再構築するときに、まったく同じJDKとまったく同じAntバージョンを使用していることを確認しない限り、これは名前が異なるだけの同じ問題です。バージョンの範囲については、すべての直接および推移的な依存関係に対してロックされたバージョンの一時的なpomを作成し、それをMavenリリースライフサイクルの一部にするプラグインで作業することをお勧めします。これにより、リリースビルドpomは常にすべての依存関係の正確な説明になります。

それはそれが得た評判に値する。誰もが、Mavenの開発者がすべての単一のプロジェクトに適切であると考える厳格な構造を必要としているわけではありません。それはとても柔軟性がありません。そして、多くの人々にとっての「プロ」、依存関係管理は、私見の最大の「詐欺」です。私はmavenがjarをネットワークからダウンロードすることに完全に慣れておらず、非互換性のために睡眠を失っています（そうですね、オフラインモードが存在しますが、なぜ何百ものxmlファイルとチェックサムが必要なのです）。使用するライブラリを決定し、多くのプロジェクトで、ネットワーク接続に依存するビルドについて深刻な懸念があります。

さらに悪いことに、物事が機能しない場合、あなたは絶対に失われます。ドキュメントはひどい、コミュニティは無知です。

1年後、私はこれを更新したいと思いました。Mavenコミュニティについてのこの意見はもうありません。今日質問された場合、私はこの回答を書きません。私の現在の意見を別の回答として追加します。

これは非常に主観的な答えですが、質問は意見に関するものなので、...

私はMavenが好きで、より多くのことを知るようになるにつれて、より好きになりました。ただし、私の感情に影響を与えている1つのこと：Mavenコミュニティは、主にSonatype（「Maven Company」であり、多くのMaven honchosが機能している場所）を中心としており、Sonatypeは、企業製品をコミュニティにかなり積極的に押し出しています。

例：「Maven Book」のTwitterストリームは、想定されるリポジトリ管理の概要にリンクしています。

申し訳ありませんが、その「イントロ」は情報の半分、ネクサスの売り込みの半分です。ポップクイズ：NexusとNexus Pro以外に他のリポジトリマネージャーはいますか？また、これはおそらくオープンソースのMaven Bookとどう関係しているのでしょうか？ああ、そうです、リポジトリ管理に関する章は別の本に分かれています... Nexusについて。ええと。Mavenブックに寄稿した場合、Nexusの売上を増加させると紹介料がもらえますか？

Java開発フォーラムに参加していて、Javaについて話し合っているSunの従業員が、NetBeansと「NetBeans Pro」について話す機会をすべて獲得することは明らかだったと想像してください。しばらくすると、コミュニティの感情が失われます。Antでそのような経験をしたことはありません。

それをすべて言っても、Mavenはソフトウェア開発の構成とビルド管理のための非常に興味深く、有用なシステムだと思います（私はそれをAntのようなツールとは呼びません。Mavenはそれより広いです）。依存関係の管理は時々祝福と呪いですが、それは新鮮です-そして確かにMavenが提供する唯一の利点ではありません。私はおそらくSonatypeシリングに少し強く反応しすぎていると思いますが、私の意見では、連想によってMavenを傷つけます。この意見が他の誰かと共有されているかどうかはわかりません。

Mavenはプロジェクトに構造を課すため、不適切なラップを取得すると思いますが、Antなどの他のツールを使用すると、構造を自由に定義できます。ドキュメンテーションが悪いことにも同意しますが、私は主にMavenが受ける悪いラップは、人々がAntにとても慣れているためだと思います。

魔法が多すぎます。

満足していない人は不満を言うのに対し、満足している人は満足しているとは言わないからです。私のポイントは、不満よりもはるかに満足したmavenユーザーがいるということです。これも実際の生活の一般的なパターンです（ISP、電話キャリア、トランスポートなど）。

私にとって単一の最も重要な問題は、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つのプロファイルを取得しました）。

それで、それはかなり頭痛の種でした。ドキュメンテーションは必ずしも優れているとは限りませんが、Googleでの回答は比較的簡単だったと認めなければなりません。

使用するプラグのバージョンを常に指定してください。新しいバージョンに下位互換性があることを期待しないでください。

論争はmavenがまだ進化していて、プロセスが時々苦痛であるという事実から来ていると思います。

よろしく

v。

私はメイベンが好きです。1.0より前から使用しています。これは強力なツールであり、全体としてかなりの時間を節約し、開発インフラストラクチャを改善しました。しかし、私は一部の人々が持っている欲求不満を理解することができます。3種類のフラストレーションが見られます。

1. 原因が本当の懸念である場合（例：詳細なPOM、ドキュメントの欠如）、
2. 一部は誤った情報です（たとえば、「構築するにはインターネット接続が必要です」-真実ではありません-これは避けられます）。
3. 一部はmavenでベントされていますが、実際には誰かが不法行為です（「メッセンジャーを撃たないでください」）。

最初のケースでは、実際の問題-まあ、確かに、問題があり、POMは冗長です。それにもかかわらず、Mavenを使用すると、短時間で良好な結果を得ることができます。antでビルドされたプロジェクトを取得するたびに私はうんざりして、これを私のIDEにインポートしようとします。ディレクトリ構造の設定には時間がかかる場合があります。mavenでは、POMファイルをIDEで開く場合にすぎません。

2番目のケースでは、Mavenは複雑であり、誤解が一般的です。Maven 3がこの複雑さ（または認識されている複雑さ）に対処する方法を見つけることができれば、それは良いことです。mavenにはかなりの投資が必要ですが、私の経験では、投資はすぐに元が取れます。

最後の点については、mavenの推移的な依存関係に関する不満がおそらく最もよく知られている例だと思います。

推移的な依存関係は、再利用を採用する実際のソフトウェアの性質です。Windows DLL、Debianパッケージ、javaパッケージ、OSGiバンドル、さらにはC ++ヘッダーファイルにもすべて依存関係があり、依存関係の問題に悩まされています。2つの依存関係があり、それぞれが同じものの異なるバージョンを使用している場合は、どういうわけかそれを解決する必要があります。Mavenは依存関係の問題を解決しようとするのではなく、むしろ最前線に立ち、競合を報告し、プロジェクトの階層に一貫した依存関係を提供するなど、問題の管理に役立つツールを提供し、実際に完全な制御を提供しますプロジェクトの依存関係。

各プロジェクトに依存関係を手動で含める方法（ある投稿者は、すべての依存関係をソース管理にチェックインしていると述べています）は、依存関係の更新をチェックインせずにライブラリが更新されると、見落とされている更新など、誤った依存関係を使用するリスクを冒しています。どんな規模のプロジェクトでも、依存関係を手動で管理すると間違いなくエラーが発生します。mavenを使用すると、使用するライブラリのバージョンを更新でき、正しい依存関係が含まれます。変更管理では、（プロジェクト全体の）依存関係の古いセットを新しいセットと比較できます。また、変更は慎重に調査、テストできます。

Mavenは依存関係の問題の原因ではありませんが、より見やすくします。依存関係の問題に取り組む際、Mavenは、バージョン管理で手動で管理されているjarの場合のように、依存関係を暗黙的にではなく明示的に（調整によってPOMを変更）します。それらが正しい依存関係であるかどうかをサポートします。

ほとんどの批判者がMaven + Hudson + Sonarの組み合わせを観察していないため、Mavenの担当者は悪いと思います。もしそうなら、彼らは「私はどのように始めればよいのか」と尋ねるでしょうか？

Mavenを使った私のペットのおしっこ：

• XML定義は非常に不器用で冗長です。彼らは属性について聞いたことがありませんか？

• デフォルトの構成では、すべての操作で常にネットを検索します。これが何かに役立つかどうかに関係なく、「クリーン」のためにインターネットアクセスを必要とすることは非常にばかげています。

• 再びデフォルトでは、正確なバージョン番号を指定するように注意しないと、これらの最新バージョンが依存関係エラーを引き起こすかどうかに関係なく、最新の更新がネットから削除されます。言い換えれば、あなたは他の人々の依存関係管理のなすがままになります。

• このすべてのネットワークアクセスに対する解決策は、-oオプションを追加してネットワークアクセスをオフにすることです。ただし、依存関係の更新を本当に実行したい場合は、必ずオフにする必要があります。

• 別の解決策は、依存関係のために独自の「ソース管理」サーバーをインストールすることです。驚き：ほとんどのプロジェクトにはすでにソース管理があり、それだけで追加の設定なしで機能します！

• Mavenビルドは信じられないほど遅いです。ネットワークの更新をいじることでこれは軽減されますが、Mavenビルドはまだ遅いです。そして恐ろしく冗長。

• Mavenプラグイン（M2Eclipse）は、Eclipseとほとんど統合されていません。Eclipseは、バージョン管理ソフトウェアおよびAntと合理的にスムーズに統合されます。比較すると、Mavenの統合は非常に不格好で醜いです。遅いって言った？

• Mavenは引き続きバグが多いです。エラーメッセージは役に立ちません。多くの開発者がこれに苦しんでいます。

良い質問。大規模なプロジェクトを開始したばかりで、以前のプロジェクトの一部は、コードベースにモジュール性を導入することでした。

私はメイブンの悪いことを聞いたことがあります。実際、私が聞いたのはそれだけです。私が現在経験している依存関係の悪夢を解決するためにそれを紹介することを検討しました。Mavenで見た問題は、構造が非常に固定されていることです。つまり、機能するためには、プロジェクトのレイアウトに準拠する必要があります。

ほとんどの人が言うことはわかっています。構造に合わせる必要はありません。確かにそれは事実ですが、最初の学習曲線を超えて、時間をかけすぎてすべてを捨ててしまうまで、これはわかりません。

最近はAntがよく使われ、大好きです。それを考慮に入れて、Apache Ivyと呼ばれるあまり知られていない依存関係マネージャーに出会いました。IvyはAnt に非常によく統合されており、基本的なJAR取得のセットアップと動作をすばやく簡単に行うことができます。Ivyのもう1つの利点は、非常に強力でありながら非常に透過的であることです。scpやsshなどのメカニズムを使用してビルドを非常に簡単に転送できます。ファイルシステムまたはリモートリポジトリでの「チェーン」依存関係の取得（Mavenリポジトリの互換性は、その一般的な機能の1つです）。

とは言っても、結局使用するのは非常にイライラすることに気づきました-ドキュメントは十分ですが、悪い英語で書かれているので、デバッグしたり、何がうまくいかなかったりするときにイライラする可能性があります。

このプロジェクトの途中で、Apache Ivyを再検討する予定です。正しく動作するようにしたいと思っています。それがしたことの1つは、チームとして、依存しているライブラリを調べて、ドキュメント化されたリストを取得できるようにすることでした。

最終的には、個人/チームとしてどのように働いているか、依存関係の問題を解決するために何が必要かがすべてだと思います。

Ivyに関連する以下のリソースが役立つ場合があります。

• Apache IvyとMaven 2の比較
• Apache Ivy FAQ
• Apache Ivy機能リスト

私はMavenが大好きです-生産性が向上し、Antを使用しなくなったことをとても嬉しく思います（ふw！）

しかし、私が物事を変えることができれば、それは次のようになります

1. メイクpom.xmlファイルそれほど冗長
2. リポジトリからではなく.jarを簡単に含めることができます。

人々がMavenを好きではない理由はたくさんありますが、それに直面すると、彼らは非常に主観的です。いくつかの優れた（そして無料の）書籍、より優れたドキュメント、より多くのプラグイン、多くの参照用の成功したプロジェクトビルドを備えた今日のMavenは、1、2年前のMavenと同じではありません。

単純なプロジェクトでMavenを使用するのは非常に簡単です。プロジェクトが大きく複雑な場合、Mavenの哲学についての知識と理解を深める必要があります。おそらく、会社レベルでは、ネットワーク管理者のようなMavenの第一人者の立場です。Mavenの嫌いな主な情報源は、しばしば無知です。

Mavenのもう1つの問題は、Antなどの柔軟性の欠如です。しかし、覚え書きのMavenには一連の規則があります-最初はそれらに固執するのは難しいようですが、結局のところ、問題から解放されることがよくあります。

Mavenの現在の成功は、その価値を証明しています。もちろん、誰も完璧ではなく、Mavenにはいくつかの短所と奇妙な点がありますが、私の意見では、Mavenはゆっくりと相手を揺さぶっています。

混合担当者がいるほど、担当者が悪いとは言えません。プロジェクトがMavenによって提唱された「構成上の慣習」のパラダイムに従う場合、プロジェクトから多くのレバレッジを得ることができます。プロジェクトがMavenの世界観にうまく適合しない場合は、負担になる可能性があります。

そのため、プロジェクトを制御できる場合は、Mavenが適しています。しかし、あなたがそうせず、レイアウトがMavenのファンではない誰かによって決定された場合、それは価値があるよりもトラブルになるかもしれません。最も幸せなMavenプロジェクトは、おそらくMavenプロジェクトとして始まったプロジェクトでしょう。

私には、社内プロジェクトでMavenとantを使用することの短所と同じくらい多くの長所があります。ただし、オープンソースプロジェクトの場合、Mavenは多くのプロジェクトをより簡単に構築できるようにするのに大きな影響を与えたと思います。平均的なOSS Java（antベース）プロジェクトのコンパイル、大量の変数の設定、依存プロジェクトのダウンロードなどに数時間かかったのはそれほど昔のことではありませんでした。

MavenはAntと同じように何でもできますが、Antが標準を推奨していない場合、Mavenはその構造に従うことを強くお勧めします。確かに、Antで簡単に設定できるMavenの設定にはいくつかの問題がありますが、最終結果は、ほとんどの場合、プロジェクトをチェックアウトして実行したいだけの人の観点から構築する方が簡単です。

あなたがビジネスや仕事を開発プロジェクトに賭けるつもりなら、あなたは基盤、つまりビルドシステムを制御したいと思うでしょう。Mavenでは、あなたはコントロールできません。宣言的で不透明です。Mavenフレームワークの開発者は、透過的または直感的なシステムを構築する方法を知りません。これは、ログ出力とドキュメントから明らかです。

依存関係の管理は、プロジェクトの開始時にある程度同じになる可能性があるので非常に魅力的ですが、警告されます。根本的に壊れており、最終的には多くの頭痛の種になります。2つの依存関係に互換性のない一時的な依存関係がある場合、チーム全体のビルドを中断し、数日間開発をブロックする複雑なネズミの巣によってブロックされます。また、Mavenを使用したビルドプロセスは、ローカルリポジトリの状態に一貫性がないため、チーム内のさまざまな開発者にとって一貫性がないことで有名です。開発者が環境を作成した時期や、開発者が取り組んでいる他のプロジェクトに応じて、結果は異なります。ローカルリポジトリ全体を削除していて、Mavenがdevブランチの最初のセットアップよりもはるかに頻繁にjarを再ダウンロードしていることがわかります。OSGIは、この根本的な問題を解決しようとしているイニシアチブだと思います。何かがそれほど複雑である必要があるなら、基本的な前提は間違っていると私は言うでしょう。

私は5年以上の間、Mavenのユーザー/犠牲者であり、依存関係をソースリポジトリにチェックして、素敵でシンプルなantタスクを記述するだけで、はるかに時間を節約できると言わざるを得ません。antを使用すると、ビルドシステムの動作を正確に把握できます。

私は、Mavenの問題のために、数週間に渡って数社の企業で多くの人を失った経験があります。

私は最近、古いGWT / Maven / Eclipseプロジェクトを復活させようとしましたが、余暇の2週間後には、一貫してビルドすることができません。私の損失を削減し、アリ/日食を使用して開発する時が来たと思います...

短い答え：Mavenビルドシステムを維持するのは非常に難しいことがわかったので、できるだけ早くGradleに切り替えたいと思います。

私はMavenで4年以上働いています。私は自分がビルドシステムの専門家だと思います。私が参加した最後の（少なくとも）5社で、ビルド/デプロイインフラストラクチャの大幅な改修を行ったからです。

私が学んだいくつかの教訓：

• ほとんどの開発者は、ビルドシステムについて考えることに多くの時間を費やす傾向はありません。その結果、ビルドはハックのスパゲッティの混乱に変わりますが、その混乱がクリーンアップされて合理化されると、彼らはそれを高く評価します。
• 複雑さを扱う場合、Mavenのように厳格な制限を課すことで複雑なことを単純化しようとするシステムよりも、複雑さ（Antなど）を公開する透過的なシステムが欲しいです。LinuxとWindowsを比較してください。
• Mavenには、ビザンチンの回避策を必要とする機能に多くの穴があります。これにより、POMファイルが理解できなくなり、維持できなくなります。
• Antは非常に柔軟で理解しやすいですが、Antファイルは低レベルであるため、かなり大きくなる可能性もあります。
• 重要なプロジェクトの場合、開発者はツールが提供するものを超えて独自のビルド/デプロイ構造を作成する必要があります。構造のプロジェクトへの適合性は、維持がいかに簡単であるかに大きく関係します。最高のツールは、構造を作成する上であなたをサポートし、あなたと戦うことはありません。

私はGradleを少し調べましたが、両方の世界で最高になる可能性があり、宣言型と手続き型のビルド記述を組み合わせることができるようです。

プロジェクトの作成に使用した言語よりも複雑です。正しく構成することは、実際のプログラミングよりも困難です。

私はここで言及されたほとんど/すべての否定的な点、およびチームメイトからの同様の異議に取り組み、それらすべてに同意しました。しかし、私はそれを突き刺しました。Maven（またはおそらくGradle）だけが実際に達成する1つの目的に固執することで、これを続けます。

ピア（オープンソース開発者）向けに最適化している場合は、ant / make / whateverが実行します。非ピア（ユーザー）に機能を提供する場合は、maven / gradle / etcのみが機能します。

mavenだけが、ソースコードとpomsの小さなバンドル（不可解な名前の埋め込まれたlib / binary依存jarがなく、依存関係情報がない）をリリースできます開発者の特異なレイアウト規則。そして、不足している依存関係を取得しながらすべてをビルドするワンボタンのインストール手順（mvn install）があります。

その結果、それらのユーザーがコードにたどり着くための追跡が簡単にできるようになりました。pomは、関連するドキュメントをユーザーに示すことができます。

その（必須の）要件は別として、私はmavenを誰よりも嫌いです。