8

私が行うサイドプロジェクトがあります=Javaで。これは非常に単純なWebアプリです。Linuxサーバー上のTomcatで実行され、MySQLデータベースを使用します。コードの大部分はSpringFrameworkで書かれています。多くのユニットテストが実施されています。私がコーディングしているとき、それはEclipseにあります。アプリケーションをデプロイするとき、いくつかのシェルスクリプトを実行して、WARファイルをWebサーバーに移動し、データベースを更新し、apache構成に変更を加えます。私はそれに取り組んでいる唯一の開発者であり、現在は1つの環境(本番環境)にのみデプロイされていますが、いつかテスト環境やステージング環境も必要になるかもしれません。Eclipseプラグインを介してSVNバージョン管理を使用しています。

プロジェクトにMavenを使用している人の話をいつも聞いています。たくさんの人が使っているので、いいと思います。暇なときに学びたいです。唯一のことは、Mavenを使用したい理由があまり売れていないということです。私の最初の段落は、Mavenに適したプロジェクトのように聞こえますか?データベースと相互作用するプロジェクトに特定の利点はありますか?

4

10 に答える 10

11

Maven は、プロジェクトの IMO に適しています。Maven は、万能のビルドおよびデプロイメント管理ツールです。最大の強みは、機能的に同等の Ant ファイルやシェル スクリプトよりも、ビルド スクリプトの保守が大幅に容易になることです。

Maven を使用することには多くの利点があります。最大の利点は、構成よりも規約が優先されることです。これは、Maven ディレクトリ構造を使用してプロジェクトを配置した場合、JUnit テストをビルドして実行するために必要な構成がほとんどないことを意味します。

Maven がもたらすもう 1 つの大きなメリットは、依存関係の管理です。プロジェクト オブジェクト モデル (POM) と呼ばれる Maven の構成ファイルで、プロジェクトの依存関係を宣言的に定義できます。Maven は、すべての jar を維持するローカル ディレクトリ構造に格納する作業を行います。公開されているアーティファクトの場合、jar は Maven 中央リポジトリから自動的にダウンロードされます。内部または独自のサードパーティ jar の場合は、1 つのコマンドでそれらをリポジトリにインストールできます。

これらのアーティファクトを整理し、ビルド クラスパスを自動的に設定して必要なすべての jar を含めるだけでなく、maven は依存関係の階層も管理します。つまり、プロジェクトが jar A に依存し、A が jar B に依存している場合、ビルド構成で依存関係として明示的にリストしていなくても、jar B は自動的に WAR にバンドルされます。

また、専門的な開発の観点から言えば、Maven を学ぶことは理にかなっています。私の経験では、Maven は、オープン ソース プロジェクトとプロプライエタリ Java プロジェクトの両方で、デ ジュール ビルド ツールとして Ant を追い抜いたからです。

以上のことから、高速で信頼性の高いビルド システムを使用している場合、他のユーザーと同じツールを使用するためだけに Maven に変換する価値はないかもしれません。

于 2008-09-19T20:36:40.483 に答える
8

Mavenは、あなたがやりたいことには問題ありません。ほとんどのビルド ツールとは異なり、maven は規則を賢明に使用し (少なくとも他の多くのツールよりも優れています)、言及したすべての領域に「プラグイン」があります。

単体テスト: maven Surefire プラグイン

Eclipse 統合: m2eclipse

WAR ファイルのデプロイ: WAR プラグインDeploy プラグイン

cargo pluginを使用して war を開始、停止、または展開できるため、Maven は Tomcat での統合テストにも役立ちます (ある場合) 。

とにかく、暇なときに読む予定がある場合は、無料の本 (PDF 形式) をご覧ください: Maven the definitive guide

それが役に立てば幸い!

于 2008-09-19T20:57:39.760 に答える
6

私は仕事で怒りの中でMavenを使用しています。それは厳しい愛人です。他の多くの人が持っていることをしている限り、それは物事を簡単にします。そして、Mavenがあなたがそれらをすべきだと考える方法でそれらをしている限り、これは重要です。その狭い道を降りてください、そうすればそれは道のあらゆる段階であなたと戦うでしょう。

BuildRをサイドで使用していることに感銘を受けました。Mavenの依存関係システムを活用しながら、ANTのように柔軟に対応できます。また、インキュベーション中なので、端が少し荒いです。

于 2008-09-19T20:33:03.050 に答える
4

Mavenを使用していた新しい一時ジョブを開始したことがあります。Maven ビルドがどのように機能するかを把握するために 2 日間費やしました。彼らはすべて Windows で maven 1.01 を使用していたことが判明し、うっかり 1.02 でビルドしようとしていたため、うまくいきませんでした。その場所には誰もそれがどのように機能したか新しいものはなく、彼らは何ヶ月もそれを使用しており、それに満足していました. 数か月後、同じプロジェクトで、ジェリー スクリプトを深く掘り下げて、1 つのビルド変数を変更する必要がありました。楽しくなかった。

私が最初にそれを使い始めたとき、私は「設定より規約」と「ディレクトリの標準セットを使用する」を読みました。これらはドキュメントのどこにもありませんでした。私はあなたが推測することになっていたと思います。

私の意見:

  • 完全に理解していないツールを使用するのは間違いであり、開発プロセスのボートアンカーになる可能性があります。ツールが非常に複雑な場合は、深くマスターするよりも、最も単純な部分を使用する傾向があります。ツールの最も強力な部分を使用していない、または避けている場合は、その使用目的を達成できていない可能性があります。
  • Maven は、ビルド ツールが Maven Maven になるのに値するよりもはるかに多くの時間を費やさない限り、自動魔法の良さに満ちているものの典型的な例です。問題を探して過剰に設計されたソリューション。
  • Ant では実行できず、maven が必要な、実行する必要のあることのインスタンスは見つかりませんでした。いくつかあることは知っていますが、それらは必要ありませんでした。もしそうなら、maven に対処するために必要な労力に関して、おそらくもっと慈善的になるでしょう。
  • ビルドがインターネットに依存するようになります。小さなプロジェクトをダウンロードし、mvn を実行し、最初にビルドしようとしているもののビルドを開始する前に、maven に 10 個のプラグインをダウンロードさせることは、今では珍しくありません。それは何をしているのですか?正確にはわかりませんが、壊れないことを願っています。失敗した場合、失敗の複雑さと依存関係の積み重なったレイヤーにより、デバッグは本質的に絶望的になります。これが単純なビルド ツールの改善である理由や、何らかの理由で望ましいことでさえある理由がわかりません。

要約すると、それはほとんど魔法のようですが、うまくいかないときはその理由がわからない可能性があります。これは悪いトレードオフのようです。これは、公平を期すために、数年前のことです。私は不親切であることを知っており、それはその後のバージョンで改善されています (私も使用しました)。それでも、私はそれが嫌いでした(わかりますか?)

于 2008-12-16T22:21:11.960 に答える
4

あなたのプロジェクトは、Maven に適したプロジェクトとは思えません。あなたは実用的な開発環境を持っているようです。なぜ別のものを設定するのですか?これは、古き良きDRYの原則を破る、維持するプロジェクト ファイルをもう 1 つ提供するだけです。

于 2008-09-19T22:15:36.673 に答える
3

私たちはあなたが私たちのプロジェクトで行うこととまったく同じことを行い、maven を使用します。Maven を使用して、標準化されたレイアウトとプロジェクトをビルドする方法を使用する必要があります。これらすべての jar 依存関係を SVN に保存したり、特別な場所に保管したりする必要はありません。maven がそれを行います。Maven は、他の開発者がプロ​​ジェクトを簡単に理解できるようにする手段としても機能します。一度使い始めると、もう振り返りたくなくなります :)

于 2008-09-19T20:33:49.833 に答える
2

多くの oss プロジェクトが maven を使用 (または Maven に変換) しており、一部のクローズド ソース プロジェクトが Maven に移行しているという事実は別として、あなたのプロジェクトは Maven を使用することで必ずしも多くの恩恵を受けるとは限りません。

ただし、オープンソース化を検討する場合、プロジェクトのユーザーは、maven を使用するプロジェクトから利益を得る可能性があります。

Maven (jar の依存関係) の重要な利点のいくつかは、ivy ( http://ant.apache.org/ivy/ ) で利用できます。

繰り返しますが、あなたはあなたが唯一の開発者であることを示しているようです。Maven が機能しない場合は、すぐに元に戻すことができます。

BR、
~A

于 2008-09-19T22:33:13.527 に答える
1

しないでください。他の人が言っていることを見て、注意深く調べてください。また、SO に関する Maven に関する私の他のコメントも参照してください。

于 2008-12-16T21:48:20.827 に答える
0

Mavenの大きな強みの1つは、ビルドスクリプトを記述したり、ビルドプロセスを記述したりすることなく、多くのビルド/依存関係管理を実行できることです。すでにプロジェクトをセットアップしているので、Mavenがプロジェクトシェルをセットアップしたり、指定した依存関係をダウンロードしたりしても、個別にダウンロードしなくてもメリットはありません。Mavenの使用方法と管理方法を学ぶことが目標である場合、他の開発者がいないこのようなプロジェクトでそれを行うことは、ビルドプロセスが非常に単純である(私が知る限り)こともあまり役に立ちません。したがって、既存のプロジェクトにMavenを使用しないことをお勧めします。

ただし、Mavenを使用して同様の単純なテストアプリケーションをセットアップし、それをプロジェクトの構造と比較して、ベストプラクティスに従っているかどうか(少なくともMaven開発者が見ているように)、アプリケーションが標準のWebアプリケーション規則に従っているかどうかを確認します。

于 2008-12-16T23:10:48.833 に答える
0

別のボックスなどでテストしたい場合は、すべてのjarを追加するのにうんざりしていたので、依存関係の管理にmavenを使用しました。このために「学習」する必要はありません。学習するまでにそれほど時間はかかりません。

しかし、最も簡単な方法は、すでに mvn を知っている人に尋ねることです。そうすれば、mvn がどのように機能するかを教えてくれるので、すぐに習得できます。

于 2008-12-16T22:12:55.597 に答える