ant、maven、buildrを使用する意味は何ですか?ビルドインEclipseまたはNetBeansの使用は正常に機能しませんか?拡張ビルドツールの目的と利点が何であるかを知りたいだけです。
10 に答える
依存関係の管理: ビルド ツールは、依存関係を探す場所に関するヒントを提供するコンポーネント モデルに従います。Eclipse / Netbeans では、JAR に依存する必要があり、この JAR が更新されているかどうかはわかりません。これらのビルド ツールを使用すると、依存関係の更新を「認識」し (通常、ソース管理リポジトリとの適切な統合により)、推移的な依存関係を再計算し、すべてが常に最新バージョンでビルドされるようにします。
アクセス制御: クラス レベルのアクセス制御を除けば、Java には高度な抽象化はありません。これらのビルド ツールを使用すると、依存するプロジェクトを正確に指定し、より高いレベルの粒度で可視性とアクセスを制御できます。
カスタム コントロール: Eclipse / Netbeans ビルドは常に JAR ファイルをビルドします。カスタム ビルド メカニズムを使用すると、必要に応じて、追加のメタデータ情報を含む独自のカスタム (社内) アーカイブを作成できます。
プラグイン: ビルド中にさまざまなことを実行できるビルド ツールに付属するさまざまなプラグインがあります。Javadoc の生成などの基本的なものから、テストの実行やコード カバレッジの取得、静的分析、レポートの生成などのより重要なものまで。
Transport : 一部のビルド システムは、開発システムから展開または運用システムへのアーカイブの転送も管理します。したがって、輸送ルート、スケジュールなどを構成できます。
CruiseControlやHudsonなどの継続的インテグレーション サーバーを見てみましょう。また、Maven の機能ページでは、知りたいことについての洞察が得られます。
他のすべての答えに加えて。NetBeans や Eclipse を使用せざるを得ずにプロジェクトをビルド可能にしておく主な理由は、自動化された (そして継続的な) ビルドのセットアップが非常に簡単になるからです。
どういうわけかEclipseを起動し、リポジトリからソースを更新し、すべてをビルドし、結果をメールで送信し、出力を最後の50個のビルドがあるディスクのどこかにコピーするサーバーをセットアップするのは(比較して)かなり複雑です。保存された。
あなたが 1 人の開発者または非常に小さなグループの場合、ビルド システムは単なるオーバーヘッドのように思えるかもしれません。開発者の数が増えると、すべての変更を追跡し、開発者が同期していることを確認することが急速に難しくなります。ビルド システムは、チームが成長するにつれて、これらのオーバーヘッドの増加率を減らします。プロジェクトで 100 人以上の開発者が作業するようになったら、Eclipse ですべてのコードをビルドする問題について考えてみてください。
個別のビルド システムを用意する説得力のある理由の 1 つは、SCM にチェックインされたコードの特定のバージョンから顧客に提供されたものをコンパイルすることです。これにより、「自分のマシンで動作する」問題のクラス全体が解消され、私の意見では、この利点は、サポート時間を短縮するために努力する価値があります。分離されたビルド (たとえば、CI サーバー上) は、開発中の問題 (たとえば、部分的または重大な変更がコミットされた場所) も強調するため、問題を早期に発見するチャンスがあります。
IDE でのビルドは、たまたまボックスにあるものをビルドしますが、スタンドアロンのビルド システムでは、再現可能なビルドを SCM から直接生成します。もちろん、これは IDE 内で実行できますが、知る限り、Ant や Maven などを呼び出してすべてのビルド手順を処理する必要があります。
もちろん、ビルドシステムの直接的なメリットもあります。モジュラー ビルド システムにより、コピー アンド ペーストの問題が軽減され、依存関係の解決やその他のビルド関連の問題が処理されます。これにより、開発者はコードの配信に集中できるようになります。もちろん、すべての新しいツールには独自の問題があり、関連する学習曲線により、ビルドシステムが不必要なオーバーヘッドであると思われる可能性があります (Google だけでは、Mavenを理解するのが嫌いです)。
IDE からビルドする際の問題は、ビルドに影響を与える設定がたくさんあることです。ビルド ツールを使用すると、すべての設定がスクリプトまたは構成ファイルの小さなセットに多かれ少なかれ読みやすい形で凝縮されます。これにより、理想的なケースでは、手動セットアップをほとんど行わずに誰でもビルドを実行できます。
ビルド ツールがなければ、すべての設定をリバース エンジニアリングする必要があるため、たとえば 1 年でコードをコンパイルすることさえほぼ不可能になる可能性があります。
さまざまな機能。たとえば、Maven は依存関係をスキャンして、それらとその依存関係をダウンロードできるので、その必要はありません。中規模のプロジェクトでも、非常に多数の依存関係が存在する場合があります。私はEclipseがそれを行うことができるとは思わない。
@匿名、
- あなたのチームのメンバーである私が、常に IDE を使用していると思うのはなぜですか? ヘッドレス ビルド サーバーでコードをビルドしたいのですが、よろしいですか?
- 継続的インテグレーション エンジンを使用する権利も拒否しますか?
- 中央リポジトリから依存関係を取得してもよろしいですか? どうやってやるの?
- 特定の IDE に関連付けてくれますか? 非常に古いラップトップでは Eclipse を簡単に実行できませんが、新しいラップトップを購入します。
たぶん、subversion もアンインストールしてパッチを使用するか、sftp/ftp/Samba 共有のフォルダーを圧縮する必要があります。
ビルド ツールを使用すると、人間の発明なしに自動的にビルドを実行できます。これは、(私たちのように) 多くのアプリケーションをビルドできるコード ベースがある場合に不可欠です。
私たちは、コード ベースが変更された後でも、すべてのアプリケーションが正しくビルドできることを確認したいと考えています。これを確認する最善の方法は、Continouos 統合ツールを使用してコンピューターに自動的に実行させることです。コードをチェックインするだけで、CI サーバーが変更を検出し、その変更の影響を受けるすべてのモジュールを再構築します。何かが壊れた場合は、責任者に直接郵送されます。
物事を自動化できることは非常に便利です。
Jens Schauder の回答を拡張するために、これらのビルド オプションの多くは、ある種の .project ファイルになります。Eclipse の欠点の 1 つは、すべてのプロジェクト ファイルに絶対パス名が格納されることです。そのため、あるマシンから別のマシンにプロジェクト ファイルをコピーすることはできません。別のディレクトリにワークスペースがある可能性があります。
私にとって最大の理由は、自動ビルドです。
IDE は、より高い抽象化レイヤーで動作するだけです。
NetBeans は、基本的なビルド ツールとして Ant をネイティブに使用しており、最近では、NetBeans で Maven プロジェクトを直接開くことができます。したがって、典型的な NetBeans プロジェクトは ant でコンパイルでき、maven プロジェクトはすでに NetBeans プロジェクトです。
GUI と CLI の議論と同様に、IDE は初心者にとっては簡単に思えますが、アイデアをつかむと、複雑なことを行うのが面倒になります。
IDE で構成を変更するということは、どこかをクリックすることを意味します。これは、基本的なことは簡単ですが、複雑なことについては、クリックする適切な場所を見つける必要があります。さらに、IDE は重要な情報を隠しているようです。ボタンをクリックしてライブラリを追加するのは簡単ですが、ライブラリがどこにあるのかわからない場合があります。
対照的に、CLI を使用するのは簡単ではありませんが、すぐに簡単になります。複雑なことをより簡単に行うことができます。
Ant または Maven を使用するということは、誰もが自分の IDE を選択してコードを操作できることを意味します。IDE X をインストールしてコンパイルするように誰かに指示することは、「シェルで <ビルド コマンド> を実行する」ように指示するよりもはるかにオーバーヘッドがかかります。そしてもちろん、前者を外部ツールに説明することはできません。
要約すると、IDE はビルド ツール自体を使用します。NetBeans の場合は Ant (または Maven) を使用するため、それらの長所と短所をすべて取得できます。Eclipse は (私の知る限り) 独自のものを使用しますが、ant スクリプトを統合することもできます。
ビルド ツール自体に関しては、Maven は Ant とは大きく異なります。プロジェクトを実行するために Web サーバーをダウンロードする時点まで、指定された依存関係をダウンロードできます。