77

この質問は Java 用 IDE との比較の拡張だと思いますが、Ant はまだ必要ですか?

上記の質問には回答がありますが、Eclipse だけでなく Maven または Ant を使用する具体的な例を知りたいです。

Eclipse で開発する場合、Eclipse がすべてを実行してくれるので、実行ボタンをクリックするだけです。また、Eclipse では、コードを実行可能な jar または Windows 用の .exe にエクスポートすることもできます。

なぜMavenやAntが必要なのか、本当にわかりません。

また、必要な場合は、Maven と Ant のどちらを選択すればよいですか?

4

5 に答える 5

87
  1. 同僚がNetBeansまたはIDEAを好む可能性があるため
  2. 設定は日食のインストールごとに異なる可能性があるため
  3. 依存関係を自動的に取得したい場合があるため
  4. ビルド全体を自動化する必要があるため:ビルド、jar、静的コード分析の適用、単体テストの実行、ドキュメントの生成、ディレクトリへのコピー、環境に応じたプロパティの調整など。
  5. 自動化されると、変更ごとまたは1時間ごとにアプリケーションをビルドする継続的インテグレーションシステムを使用して、すべてがビルドされ、テストに合格することを確認できます...
  6. Mavenは設定より規約を使用しているためです。
  7. IDEは、必要ないくつかの凝ったコード生成/変換をサポートしていない可能性があるためです。
  8. ビルドスクリプトはビルドプロセスを文書化するためです。

Eclipseは開発環境です。しかし、それはビルドツールではありません。

私は個人的にMavenが嫌いですが、YMMVです。多くの選択肢があります:gradle、buildrなど。

于 2012-05-26T07:57:30.513 に答える
11

Maven は、autoconf が最先端のコード自動化であると考えており、オブジェクト コードにはオブジェクト環境が存在する必要があることを理解していない、時代遅れの C シェル スクリプト キディによって書かれた何かのケースとして私を驚かせます。開発または展開のいずれかで効率的です。Ant は十分に悪かったのですが、Maven は Ant と Ivy の最悪の機能をすべて組み合わせています。オブジェクト環境を作成せず、作成するツールとうまく連携しません。

簡単に言うと、オブジェクト環境には、すべてのクラス オブジェクト、つまり、システムで利用できるオブジェクトの種類を決定するオブジェクトが存在し、常に利用可能である必要があります。そこから、好きなことをしたり、クラスの複数のオブジェクトをインスタンス化したり、さまざまなシーケンスやインスタンス化ルールを設定したりできます。環境は完全にライブである必要があるため、必要ありません。ビルドツールです。アプリをデプロイするという点では、アプリを構成する名前空間内のコードによって参照されることのないすべてのクラス オブジェクトを環境から単純に破棄することは難しくありません。現在、JVM のガベージ コレクタはほぼ同じことをオンザフライで実行します。その時点で、オブジェクトと、オブジェクトが参照するすべてのオブジェクト (主にクラス オブジェクト)、つまりアプリケーションとすべての依存関係で構成された展開環境ができました。これが仮想マシンの仕組みです。(私たちの VM は非常に貧弱に書かれているため、別の Linux VM 上の VMWare VM 上の Linux VM 上の Java VM 上で Spring VM を実行する必要があることは、ソフトウェア開発の愚かさのもう 1 つの例です)。依存関係が更新されると、環境が開発者に古いコードを新しいライブラリにマージするよう促すのは簡単です。新しいライブラリを使用してコードを古いバージョンにマージするか、両方のバージョンを保持します。プロンプティングは、開発者がすべてのライブラリの 20 バージョンを避けるために時々必要となるわずかな変更を行うことを奨励しますが、Maven のようなツールは 20 バージョンがあるという事実を隠し、Java アプリで一般的な大規模なランタイムの肥大化をもたらします。

Java 開発スペースでは、Eclipse が適切なオブジェクト環境に最も近いものになっていますが、さまざまな方法でパラダイムを破るプラグインがたくさんあることは認められています。Maven を使用する理由のほとんどは、批判的に検討すると崩れます。

Netbeans と Idea は誇張されたテキスト エディターであり、オブジェクト環境ではありませんが、何千もの Eclipse プラグインでカバーされていないものにそれらのツールを使用したい場合、どちらも Eclipse プロジェクトをインポートおよび維持できます。ビルドは開発者に比べて非常に遅くなります。 Eclipseを使用していますが、純粋なNetbeansまたはIdeaプロジェクトであれば、とにかく遅くなります。

Maven を使用する重大な理由ではありません。

Eclipse での設定のエクスポート/インポートの容易さ (すべてのチームがあらゆる IDE で行うべきこと) は、さまざまな設定の問題を、開発チーム側の怠惰 (または、スペースとタブに関する宗教的な議論、笑) にすぎません。 .

繰り返しますが、Maven を使用する重大な理由ではありません。

チーム環境?GIT や SVN などのリポジトリをまだ使用していないチームを教えてください。Nexus リポジトリも設定して、機能とメンテナンスの両方の頭痛の種を複製する必要があるのはなぜですか?

それは実際にはMavenを使用しない正当な理由です。

サーバービルドを実行していますか? 素晴らしいアイデアですね。たまたま Nexus にプッシュされたランダムなビルドではなく、ソース リポジトリに実際にチェックインされたコードによって開始されるべきではありませんか? これは、Git、特に Maven を使用した Git に対する反論を引き起こします。Gitではブランチで作業しないので、ローカルでテストしてからコミットします(JenkinsとEclipseのMaven構成の違いにより、ローカルテストではサーバービルドが機能することを証明できないためです)変更をにコミットする必要がありますサーバーの Maven ビルドが失敗することを確認するために別のブランチを作成し、さらに変更をコミットして問題を修正すると、レポのソース履歴が読み取れなくなります。チェックインされたコードは、少なくとも単体テストをビルドして合格する必要があり、Git と Maven が存在しない場合は保証されます。

実際に調べてみると、Eclipse からヘッドレス ビルドをエクスポートするのは簡単です。必要なのは、ant または Gradle、Eclipse によって既に維持されている開発者ビルド、およびいくつかの Eclipse jar だけです (Eclipse は、ヘッドレス ビルドに必要なすべてのファイルをディレクトリまたは zip ファイルにダウンロードするか、ビルド サーバーに ftp します)。Hudson/Jenkins などのサーバー ビルド ツールは、ほとんどのソース リポジトリから更新されたコードを取得し、任意のビルド スクリプトを呼び出すことができます。Maven への依存はありません。Maven を使用すると、ビルド エンジニア以外の誰にも適していないツールを開発者に強制的に使用させるか (M2E を使用したとしても、ビルドにかかる時間の大きさは、そのケースを作成するのに十分です)、またはサーバーがビルドする可能性を受け入れます。ワークステーション ビルドのように機能しません大量の M2E プラグインを使用して 2 つを統合するという面倒な作業をすべて経験した場合は true です。いずれにせよ、遅くて壊れやすいサーバー ビルドのために、遅くて壊れやすいワークステーション ビルドが得られます。私が取り組んだすべての Maven ベースのプロジェクトで、考えられるすべての M2E プラグインをインストールして正しく構成しない限り、Eclipse に表示されない一時的な Hudson/Jenkins エラーを見てきましたが、ほとんどの開発者は決してそうしません。

Maven を避けるもう 1 つの大きな理由のようです。

名前空間がJava名前空間やXML名前空間を破壊するなど、Mavenのより基本的な問題のいくつかはカバーされていません.ビルドユニット(POM)は実際の展開環境とは何の関係もありません(分離するときに考えてくださいPOM を介して、最終製品で実際に何を達成していますか? 何も達成していない. それが達成しているのは、懸念事項と機能をすべて実行するさまざまなビルドユニットに分離したという誤った感覚だけです.コードの 1 つのモノリシックな部分として); 複雑な構成ファイルを手動で維持する手間。OSGi または別のコンテナーを使用する必要が生じ、Maven 構成に影響を与えたり影響を受けたりする他の構成ファイルを維持する必要がある場合にのみ悪化します。コードを実行するための完全な環境なしで単体テストを実行しようとすることによって引き起こされる問題。依存関係だけでなく、Maven 固有のプラグインの無数のバージョン (複数の Maven プラグインが競合する依存関係を使用していた Maven ビルド自体で JAR 地獄を見たことがあります。これは、Maven が解決するはずだった問題の 1 つです。

はい、Maven でオブジェクト コードを作成できます。C やアセンブラーで純粋なオブジェクト コードを書くこともできますが、なぜそうしたいのかわかりません。

Maven を避ける一番の理由は、上記のすべての問題 (および言及されていない他の多くの問題) にうんざりしたときに、一連のプロジェクトを非 Maven 化するために必要な膨大な量の作業です。

開発サイクルがコードの記述、コンパイル、アセンブル、ビルド、デプロイ、テスト、やり直しで構成されるという C 開発から継承された考え方は、オブジェクト環境では絶望的に時代遅れです。ある時点で、この考え方を持つすべての人々に、成長する方法を再学習する必要があることを伝える必要があります. そうすることで、Maven、Git、および時間を浪費するだけの他の多くのツールの必要性がなくなります。

オブジェクトの開発は、ライブ オブジェクト環境で行う必要があります。この環境では、変更されたオブジェクトがライブであるため、コードの変更が保存されるときにテストされます。展開は、その環境から開発のみのアーティファクトを削除し、実行中のアプリが開発とテストで使用するすべてのものを含むランタイムを作成することで構成する必要があります。

現在、maven-assembly プラグインを使用して OSGi アプリのデプロイメント アセンブリを作成することによって引き起こされる問題に対処しています。アプリは Eclipse 環境で完全に動作し、環境内で実行中の OSGi コンテナーにすべてのコード変更をホット デプロイします。ただし、そのプロセスを達成することが唯一の仕事である非常に優れた構成/ビルドエンジニアがいるにもかかわらず、構成はmaven-assemblyプロセスを通じてそのまま残るわけではありません。Maven を取り除き (コードの量が多いため現在は非常に困難ですが、可能です)、BNDTOOLS Eclipse プラグインを使用すると、Eclipse ビルドを Ant または Gradle ヘッドレス ビルドとして簡単にエクスポートできます (BND を作成する OSGi 開発者とBNDTOOLSはしませんMaven をサポートしており、正当な理由により、Maven プラグインは、Netbeans と Maven を使用する Felix 開発者によって作成されており、展開サイクルの最後以外のライブ環境はありません)。両方のツールがEclipseと同じ環境をセットアップします。いずれにしても、開発者のみを対象とした GUI オブジェクトはありません。結果として、デプロイ用の同一の構成とビルドが作成されます。これにより、現在遅い Maven または M2E ビルドの監視に費やしていた開発者 1 人あたり 1 日あたり 2 ~ 3 時間を簡単に節約でき、構成/ビルド エンジニアはデプロイ ホストでアプリのテストをさらに行うことができます。

書き込み/コンパイル/アセンブル/ビルド/デプロイ/テストの考え方を克服することは、唯一の大きな障害です。最新のマシンではなく 1979 年の VT100 端末でコーディングしているふりをしても、「本物の」開発者にはなりません。それは、あなたのメソッドが 35 年も古いことを示しているだけです。

チームの開発者の中で、Eclipse のようなライブ オブジェクト環境を M2E や OSGi でライブ環境として機能させるのに十分なほど十分に理解している開発者は他にいません。時代遅れのコマンドライン開発ツールの普及に。彼らは、構成の問題を解決するためにペア プログラミングを行ってい、私が自分の画面を共有していて、他のチーム メンバーの 1 人が「それは私のコードの変更がバックグラウンドの OSGi コンテナーで即座にテストされるのを見たとき、彼はどのようにコードを書くのか非常に高速です。実際、私はその環境からできるだけ早く抜け出し、21世紀に戻ることができるように、かなり効率的に正確にそうしています.

于 2014-07-29T09:29:13.180 に答える
6

Ant または Maven を使用することには、非常に多くの利点があります。

Maven は多かれ少なかれ Ant の更新概念です。箇条書きで回答するのではなく、別のアプローチでこの質問に回答することにしました。簡単な質問をします。ここでは、あなたが開発者であると想定しています。または、ある種の OO プログラミングのバックグラウンドを持っている。

そのため、上司が 200 のディレクトリをコピーするように依頼した場合、jar, war and earそれらのディレクトリ内のファイルを無視し、一度コピーするとします。次に、それらの 200 のディレクトリを別の宛先にデプロイしますが、デプロイするのは.classファイルのみです。残りのファイルを別の宛先などにコピーします。

Javaでこれを行うには; 大量のロジックと大量のコードになり、拡張性や変更への適応性がなくなります。そのため、Ant または Maven は、アプリケーションが使用するオーバーヘッドを抑えて、これらすべてをオンザフライで実行および準備することを念頭に置いてください。ant または Maven のコードのサイズは、1/4Java と比較されます。

リンクをクリックすると、技術的なメリットがさらに表示されます。

メイヴン

アリ利点のある本物の答えを見つけることができませんでしたが、これであなたを納得させることができると確信しています ;)

于 2012-05-28T16:12:58.633 に答える
5

MavenとAntは、ビルドのスクリプトを作成するために使用されるため、Jenkinsやコマンドラインなどのバッチジョブで実行できます。

実際、Eclipse自体はプラグインを構築するためにAntを広範囲に使用しています。

2つのうちの1つを学び、Mavenを学ぶとしたら、それは最近ほとんどの人が使用しているものです(Antの代わりに)。

于 2012-05-26T07:55:50.217 に答える