私が管理している Java オープン ソース プロジェクトに Maven を使用することを検討しています。
ただし、これまで Maven が常に最高の評判を得ていたわけではありません。現時点で、Maven についてどのような印象をお持ちですか?
私が管理している Java オープン ソース プロジェクトに Maven を使用することを検討しています。
ただし、これまで Maven が常に最高の評判を得ていたわけではありません。現時点で、Maven についてどのような印象をお持ちですか?
オープンソースプロジェクトの場合、Mavenには、特に貢献者にとっていくつかの利点があります(mvn eclipse:eclipseなど)。
Mavenを使用する場合、宗教的に従わなければならない1つのルールは、ツールと戦わないことです。Mavenが推奨する方法でプロジェクトを正確にレイアウトし、すべての規則とベストプラクティスに従います。Mavenとの小さな戦いはすべて、プロジェクトのコードを書くために費やすことのない日です。
また、アーティファクトをデプロイする場所を事前に検討してください(独自のリポジトリをホストする予定ですか?)。
そして、Maven以外のもの(Antなど)を使用することを恐れないでください。プロジェクトの成功は、ビルドツールではなく、プロジェクト自体になります(AntとMavenの両方である最高のビルドツールを選択する限り)。
個人的には、私はファンではありません。Charles Millerが設計上壊れていると言っていることに、私はほとんど同意します。それはいくつかの問題を解決しますが、他の問題ももたらします。
Antは完璧とは言えませんが、はるかに堅牢で、ドキュメントも充実しています。ただし、モジュール方式で使用するにはある程度の規律が必要です (これは、Maven が対処しようとしているものの 1 つです)。Ant と Maven の両方より優れたものを発明することはそれほど難しくないと思いますが、そのツールはまだ存在していないようです。
Maven の依存関係管理は好きだが Maven は好きではない場合は、 Ivyを使用して Ant で同様のものを得ることができます。このスタイルの依存関係管理に関する私の問題は、制御できない要因のために壊れやすいことです。意味のある使用例の 1 つは、相互に依存する組織内のプロジェクトが多数ある場合です。この場合、すべてがあなたの管理下にあり、うまくいくかもしれません。
編集:Mavenが気に入らなくても無視できないことを追加するのを忘れていました。他の人が使用するオープン ソース ライブラリを作成する場合、Maven ビルドから簡単に使用できるように、Maven リポジトリで利用できることを期待するでしょう。
EDIT2 : あなたの主な関心は他の Maven ユーザーにオープン ソース ライブラリを提供することであることを明確にしたので、これを達成するために必ずしも Maven を使用する必要はないことに注意してください。Maven リポジトリに公開するための一連の Ant タスクがあります。したがって、引き続き Ant を使用してプロジェクトをビルドしたい場合は、Maven を使用するユーザーを満足させることができます。
プロジェクトが「単純」である場合、Mavenを使用すると非常に迅速に起動して実行できます。簡単に言うと、たくさんのコード、いくつかのリソース、いくつかのテストクラスがあり、それらすべてがいくつかのサードパーティのjarと一緒になってアプリケーションを作成します。
自分のプロジェクトに何らかの形で固有の何か変わったことをしたい瞬間、Mavenにやりたいことをさせようとすべての時間を費やし、コードの作業に時間を費やすことはありません。これは私にとって、巧妙なビルドシステムを使用するという目的を打ち破ります。
Mavenは、機能していないときに問題を診断するのに役立つことにも恐ろしいです。また、ビルドスクリプトは、直感的で不自然なxmlの読み取り不可能なスクリードであり、もちろん、これが好みであり、探しているものである可能性があります(ant-visionがある場合)。
私はMavenが大好きです。Mavenは善と約束に満ちています。私もメイヴンが嫌いです。
編集:
ああ、そしてEclipse用のMavenプラグインはフリッピンです。
Maven が 1.x から 2.x に移行するときに、Maven を使用するという不幸がありました。上級チーム メンバーの 1 人の時間のほぼ 100% が費やされました。最終的に廃棄しました。
ただし、最近、maven を再訪する機会があり、改善されたと思います。私の主な問題の 1 つは適切なドキュメントがないことですが、 「Maven: 決定版ガイド」を読んだ後は、はるかに理解しやすいと言えます。
Eclipse 用のm2eclipseプラグインとともに、依存関係の管理が面倒になります。これには、優れた依存関係の視覚化ツールがあります。
全体として、Maven はプロジェクトの開始時に優れたツールであると言えますが、ビルドが複雑になり始めると、道に迷い始める可能性があります。
Mavenにはいくつかの非常に良い点があります。
さらに、Mavenはいくつかのアリのこともできます。
私にとっての欠点は、プロジェクトを移植するのが難しいという事実です。ゼロから始めるのが最善です。また、Mavenはプラグインを使用してその仕事を広範囲に行っていますが、その点ですべてが完璧であるとは限らず、まだすべてのプラグインがありません。
ビルド ツールを使用する主な理由の 1 つは、再現可能なビルドを取得することです。つまり、今日行うビルドは、数年後に正確に複製できるということです。私の経験では、Maven は再現可能なビルドを作成するテストでひどく失敗します。
問題は、多くの可動部品を備えた大きくて複雑な獣であることから生じます。各パーツには独自のリリース サイクルがあり、バージョンが互いに競合してビルドが壊れることがよくあります。そのようなものをデバッグしようとするのは非常に複雑です。
私はオープンソースの作業に Maven を使用しています。Maven は妥当な Web サイトを比較的迅速に作成するためです。これは、オープンソース以外の開発者にとってめったに関心のないことです。この作業を行っても、なぜ物事が期待どおりに機能しないのかを突き止めようと、しばしば長い時間を費やしてきました。オープンソースの作業では、信頼できるビルド (jar) を実際に生成するために、通常は ant を使用します。
最後に 1 点。オープン ソース プロジェクトを作成している場合は、何らかの方法で Maven を使用する必要がある場合があります。プロジェクトが人気がある場合は、中央の Maven リポジトリでそれを取得する必要がありますが、Maven を使用しない場合、これは非常に難しいことです。
私は個人的に Maven が大好きで、他にも Maven を使っている人はたくさんいます。Maven2 は Maven1 よりもはるかに高い評価を得ており、OSS コミュニティではそれに向かう傾向があるようです。多くの異なるプロジェクトを抱えているショップにとって、これは一貫性を生み出すのに非常に役立ち、すべてのプロジェクトで Ant スクリプトを使用して車輪を再発明しているような気がしません。
あなたの質問に答えるには、少なくとも jar を中央リポジトリに送信していただければ幸いです。既存のビルド プロセスを maven に置き換える必要はありませんが、少なくともプロジェクトの依存関係を含む POM を維持する必要があります。
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
これにより、ユーザー (Maven または Ivy を使用する) が jar をダウンロードしてインストールするのがはるかに簡単になり、プロジェクトにメリットがあります。
Maven を使用してビルドを行うことにした場合、参入障壁がいくらか低くなるため、プロジェクトへの参加が増える可能性があります。Maven を使用してプロジェクトをビルドしたら、ソースからビルドしたい人に必要なのは、「mvn install」を実行することだけです。(FWIW、Ant/Ivy を使用してある程度同じことを達成できます)。
JavaPosse は、最近のポッドキャスト #217で Maven についてかなり議論しました。コンセンサスは、プロジェクトを構築する方法が非常に制限されていることですが、その使用は増加しており、プロジェクトを表現するためのクロス IDE 標準を提供する可能性があるということでした。
更新— Javaposse は、昨年春の Java Roundup 09 で、「Maven with Pain?」というタイトルの有益なセッションも主催しました。私は笑いました (恐ろしく同情して) レコーディングの終わりに向かって、参加者の 1 人がプラグインの更新によってビルドがどのように壊れたかについて話しました (製品リリースの 2 日前)。
正直なところ、大部分は名前がいらいらするので、私はそれを避けてきました。ただし、サードパーティ ライブラリの依存関係を管理できる機能は魅力的です。
アップデート—私の不合理な意見を不合理に軽蔑している人々のために、私の心に「メイヴン」が何を思い起こさせるかをお見せしましょう:
はい、私の考えでは、Edna Mode は「maven」の縮図です。そして、私は彼女を私のビルドに入れたくありません—あまりにも偉そうです!
より良い名前は何でしょうか?発明された言葉は、ピンポイントの Google 検索結果に最適です。良い印象を与えるには、肯定的な意味合いを持つ実際の言葉でそれらを根付かせてください。
Maven を使用する主な利点は、「プロジェクト オブジェクト モデル」を外部化することです(したがってpom.xml
)。このような独立したプロジェクト構造の利点は、ツールや IDE 間で移植できることです。
すべての主要な IDE は、Maven のサポートに多額の投資を行ってきました。選択した IDE でプロジェクトを開くと、Maven 構造が採用され、準備完了です。
通常、すべてのIDE メタデータ(.iml、.project、.classpath など) をVCS 無視リストに入れます。
明らかに、継続的インテグレーション エンジンは、POM ベースのアプローチから同様の恩恵を受けます。
学習曲線があり、制約がありますが、多くの見返りがあります。
Mavenを使用して、プロジェクトの開始から展開までのライフサイクル全体を管理できます。それらが必要な場合は、Mavenが適切なツールです。依存関係を管理するためのツールを探しているだけなら、AntのIvyも調べてみてください。
それは私が取り組んだほとんどのプロジェクトで使用されており、時にはイライラすることもありますが(構成とドキュメント)、多くの時間を節約できました。ApacheのJavaベースのプロジェクトのほとんどはMavenを使用しています。
Mavenが機能するかどうかは、実際に何をしたいかによって異なります。
yc
私たちの会社では、さまざまなコンポーネントのビルド間で統一性を確保するために、ゆっくりと Maven への移行を開始しました。現在、同じことをしようとしている ant スクリプトの巨大なマッシュアップです。それはうまく機能し、ビルドサーバー (Hudson) とうまく統合され、Maven がサポートしていない (または完全にサポートしている) 必要ないくつかのことは、基本的に、添付する単純化された ant ビルド xml に投入されました。ビルドプロセス。機能の穴をうまく埋め、簡単に変換できます - 作業を開始する必要があるのは、ベースのコンパイル/パッケージ プロセスだけです。その後、ビルドのその他の副作用があれば、時間があるときにゆっくりと ant から移行できます。
一部の友人は、Maven は NetBeans に少し似ていると私に言いました。どちらも、かつては当然のことでしたが、もはや完全には有効ではない特定の汚名に苦しんでいます。ドキュメンテーションの欠如と XML/Jelly のために、私は Maven 1.x が嫌いでした。
Maven 2 はより Java 指向であるため、後者の問題は解決される可能性があります。ドキュメンテーションが不十分であるという汚名は残っていますが、それが公正かどうかはわかりません。(それでも公平であれば、Maven チームは本当にボールを落としたことになります。)
POM と依存関係管理はどちらも優れたアイデアですが、C++ が新しい言語への道を切り開いたのと同じように、それらが新しいツールに同化されるかどうかは疑問です。
最後の注意: Ant と Maven の間の二分法は、いくぶん誤りです。Gradle と Gant は、Groovy 空間のビルド ツールであり、単純な Java プロジェクトであっても提供できるものがたくさんあります。彼らは Groovy を使用しているため、単純なタスクは本当に単純です (Ant での面倒な XML 構造とは対照的です)。それでも、Ant と強力に統合されているため、「難しい」タスクが豊富に用意されています。
ドキュメンテーションは改善されており、m2eclipse は単に素晴らしいものです。しかし、上記の誰かが「設計による破損」の記事を指摘しました。彼はいくつかの良い点を指摘しました。個人的には maven は ant よりも優れたツールだと思いますが、長い目で見れば、私たちの経験から、maven3 は maven2 よりも優れたツールになるでしょう。
私はそれなしでは生きられませんでした。インターネット接続、JDK、および Maven 2 を備えた世界中の任意のマシンに移動し、git リポジトリをチェックアウトして、「mvn test」を実行すると、ビルドされます。他のビルドツールについては、敢えて言ってください。:-)
matt raible のブログ エントリhttp://raibledesigns.com/rd/entry/comprehensive_project_intelligence_with_jasonがあります。
Maven を使用するほとんどの人は気に入らないと聞いています。
私たちは非常に大きなプロジェクト (15 個以上のモジュール) に maven を使用しており、ツールと戦わないように懸命に努力しましたが、
1) maven は一般的な問題の 90% を解決しますが、残りの 10% に苦労している場合は、いじるのが常に面倒です。
2) ライフサイクル管理がめちゃくちゃ。物事が起こるのに正しいフェーズを選択したとしても、うまくいかないことがあります。そして、あなたはその理由を知りません
3) 私たちは懸命に戦いますが、最終的にはあきらめました。Maven の ant を使用します。ant を使用して maven を呼び出すこともあります。ここで、私たちがひどいと考えようとさえしないでください: ビルド プロセスの特定のステップの複雑さを理解していただければ... 複雑なプロジェクトをビルドする場合に、maven が頻繁に邪魔をするだけです。
4) ローカルのリポジトリ管理が負担になる。Artifactory はよくありません。および他の同様の製品。
全体として、Antをお勧めします(依存関係の管理が必要な場合はIvyを使用することもできますが、試したことはありません)
さようならステファノ
私はMavenが大好きで、いつも使っています。その理由の一部は、EclipseのXMLプラグインを介してセットアップするのが非常に簡単であるということです(非常に記述的なXSDがあります)。Mavenは、リポジトリからjarをダウンロードし、必要に応じて推移的な依存関係を除外できるため、依存関係の管理にも最適です。また、該当するレポートを含むプロジェクトWebサイトを作成するのに最適なsite:siteの目標も組み込まれています。
Mavenは、開始したばかりのプロジェクトに最適ですが、ソースコードの期待される形式を備えています。Mavenでプロジェクトを開始し、すぐに何ができるかを知っていると、非常に役立ちます。しかし、あなたは間違いなくそれを研究するべきです。「箱から出して」、Mavenは素晴らしいことを行うことができ、そのためのプラグインがたくさんあります。ただし、ANTがMavenよりも適切に処理できるものもあり、Mavenプラグインがない場合は、Mavenで処理するのが難しい場合があります。ただし、独自のMavenプラグインを作成する方法もいつでも学ぶことができます。
Mavenの優れたガイドについては、Mavenを使用したBetterBuildsを参照してください。
ああ、これらのコメントはMaven 2に当てはまります。私は、Maven1を使用したことがありません。
@ MetroidFan2002:Maven 1は非推奨であり、Maven 2よりもほぼ間違いなく安定しています(機能は少ないですが)。Jellyスクリプトを書くことは間違いなく悪い考えです。
yc