GradleとMavenの比較

Javaの世界には、Ant、Maven、Gradleの3つの主要なビルドツールがあります。数年の開発の後、Antはほとんど姿を消し、Mavenも姿を消し、Gradleの開発は本格的に進んでいます。著者は幸運にもMavenの衰退とGradleの台頭を目撃しました。Mavenの主な機能は主に、依存関係管理システム、マルチモジュール構築、一貫したプロジェクト構造、一貫した構築モデル、プラグインメカニズムの5つのポイントに分かれています。これら5つの側面から、Mavenと比較したGradleの進歩を分析できます。

Mavenは、Javaの世界に新しい依存関係管理システムを導入しました。Javaの世界では、groupId、artifactId、およびversionで構成されるCoordination(座標)を使用して、依存関係を一意に識別できます。Maven自体に基づいて構築されたプロジェクトも、これら3つの属性を定義する必要があります。生成されるパッケージは、Jarパッケージ、warパッケージ、またはearパッケージのいずれかです。一般的な依存関係の参照は次のとおりです。

<dependency>
 <groupId>junit</groupId>
 <artifactId>junit</artifactId>
 <version>4.12</version>
 <scope>test</scope>
</dependency>
    
<dependency>
 <groupId>org.springframework</groupId>
 <artifactId>spring-test</artifactId>
</dependency>

上記のことから、依存関係を参照する際にバージョンを省略できるため、依存関係を取得する際に最新のバージョンが選択されることがわかります。これらのコンポーネントを保管する倉庫は、リモート倉庫とローカル倉庫に分かれています。リモートウェアハウスは、世界で一般的な中央ウェアハウスを使用できます。または、Apache Nexusを使用して独自のプライベートウェアハウスを構築できます。ローカルウェアハウスはローカルコンピューター上にあります。Mavenインストールディレクトリのsettings.xmlファイルを使用して、ローカルウェアハウスのパスと使用するリモートウェアハウスのアドレスを設定できます。

Gradleはmavenの依存関係管理システムを使用しますが、次の違いがあります。

  1. 導入された依存関係は非常に簡潔です

  2. Mavenの世界では、依存関係には6つのスコープがあります。これらのスコープは、コンパイル(デフォルト)、提供、ランタイム、テスト、システム、およびインポートです。そして、gradeは、コンパイル、ランタイム、testCompile、testRuntimeの4種類に簡略化します ???

  3. Gradleは動的なバージョンの依存関係をサポートしています。動的なバージョン管理を実現するには、バージョン番号の後に+記号を使用します。

  4. マルチモジュール構造

    SOAとマイクロサービスの波の下で、プロジェクトを複数のモジュールに分解することはすでに非常に一般的な方法です。Mavenでは、親POMをモジュールのグループの集約POMとして定義する必要があります。タグを使用して、POMでサブモジュールのセットを定義できます。親POMには実際のビルド出力はありません。親POMのビルド構成と依存構成は、自動的に子モジュールに継承されます。

    また、Gradleはマルチモジュール構築もサポートしています。親のbuild.gradleでは、allprojectsおよびsubprojectsコードブロックを使用して、内部の構成をすべてのプロジェクトまたはサブプロジェクトに適用するかどうかを定義できます。サブモジュールの定義は、setttings.gradleファイルに配置されます。Gradleの設計では、各モジュールはProjectのオブジェクトインスタンスです。親build.gradleでは、すべてのプロジェクトまたはサブプロジェクトを通じて、これらのオブジェクトに対してさまざまな操作を実行できます。これは間違いなくMavenよりも柔軟性があります。

    たとえば、次のコードは親のbuild.gradleにあります。

    一貫したプロジェクト構造
    Antの時代では、誰もが簡単にJavaプロジェクトディレクトリを作成し、Ant構成を使用して、ソースに属するものとtestSourceに属するものを指定します。設計の最初のMavenの概念は、Conversion over configurationです(慣習は構成よりも優れています)。標準のJavaプロジェクト構造として、一連のプロジェクトディレクトリ構造を開発しました。典型的なMavenプロジェクトの構造は次のとおりです。

    Gradleもこの標準のディレクトリ構造に従います。Gradleプロジェクトで標準のMavenプロジェクト構造を使用する場合、Gradleで冗長構成を行う必要はありません。ファイルに「apply plugin: 'java'」を含めるだけで、システムがソース、リソース、テストソースを自動的に識別します。テストリソースおよびその他の対応するリソース。ただし、Gradleは、JVMのビルドツールとして、groovyやscalaなどのソースコードの構築もサポートし、Java、groovy、およびscala言語の混合構築もサポートします。Mavenは一部のプラグイン(maven-scala-pluginなど)を介して同じ目的を達成できますが、Gradleが構成の点でよりエレガントであることは明らかです。

    一貫性のあるビルドモデル
    Antでのプロジェクト構築アクティビティの標準化の欠如の問題を解決するために、Mavenは特に標準のプロジェクトビルドサイクルを設定しました。デフォルトのビルドサイクルは次のとおりです。

    <phases>
     <phase>validate</phase>
     <phase>initialize</phase>
     <phase>generate-sources</phase>
     <phase>process-sources</phase>
     <phase>generate-resources</phase>
     <phase>process-resources</phase>
     <phase>compile</phase>
     <phase>process-classes</phase>
     <phase>generate-test-sources</phase>
     <phase>process-test-sources</phase>
     <phase>generate-test-resources</phase>
     <phase>process-test-resources</phase>
     <phase>test-compile</phase>
     <phase>process-test-classes</phase>
     <phase>test</phase>
     <phase>prepare-package</phase>
     <phase>package</phase>
     <phase>pre-integration-test</phase>
     <phase>integration-test</phase>
     <phase>post-integration-test</phase>
     <phase>verify</phase>
     <phase>install</phase>
     <phase>deploy</phase>
    </phases>
    

    プラグインのメカニズム

    MavenとGradleはどちらもプラグインメカニズムで設計されています。しかし、明らかにGradleの方が優れています。主な理由は、MavenがXMLに基づいて構成されていることです。したがって、その構成構文はXMLに限定されすぎています。非常に小さな機能を実装する場合でも、XML構成との関連付けを確立するプラグインを設計する必要があります。たとえば、Mavenでシェルコマンドを実行する場合、構成は次のようになります。

    <plugin>
     <groupId>org.codehaus.mojo</groupId>
     <artifactId>exec-maven-plugin</artifactId>
     <version>1.2</version>
     <executions>
     <execution>
     <id>drop DB => db_name</id>
     <phase>pre-integration-test</phase>
     <goals>
     <goal>exec</goal>
     </goals>
     <configuration>
     <executable>curl</executable>
     <arguments>
     <argument>-s</argument>
     <argument>-S</argument>
     <argument>-X</argument>
     <argument>DELETE</argument>
     <argument>http://${db.server}:${db.port}/db_name</argument>
     </arguments>
     </configuration>
     </execution>
     </executions>
    </plugin>
    

    Gradleでは、すべてが非常にシンプルになります。

    task dropDB(type: Exec) {
     commandLine ‘curl’,’-s’,’s’,’-x’,’DELETE’,"http://${db.server}:{db.port}/db_name"
    }
    

    カスタムプラグインの作成に関しては、MavenとGradleのメカニズムは似ており、どちらもプラグインの基本クラスから継承し、必要なメソッドを実装します。ここでは説明を省略します。

MavenとGradleの主な違いは、上記の5つの側面から見ることができます。Mavenの設計の中核であるConvention Over ConfigurationはGradleによってさらに促進され、Gradleの構成、つまりコードはMavenを上回っています。Gradleの構成はコードとして実行できます。また、既存のAntスクリプト(AntタスクはGradleの第一級市民)、Javaクラスライブラリ、Groovyクラスライブラリを使用して、いつでも構築タスクの作成を支援できます。独自の言語で実装されたこの種のDSLは、独自の言語プロジェクトの構築と管理の例でいっぱいです。たとえば、RakeとRuby、GruntとJavaScript、SbtとRubyなどです。GradleがGroovy言語を使用するのは、GroovyがJava言語よりも表現力があり、文法上の機能が豊富で、機能的な特徴もあるためです。近年登場した言語(Scala、Go、Swiftなど)はすべて強く型付けされた言語であり、オブジェクト指向と機能の両方の機能を備えています。最後に、GradleコマンドラインはMavenよりもはるかに強力です。以前、Gradleのコマンドライン操作に関する記事を書いたことがあります。詳細については、GradleコマンドラインBlack Magicを参照してください

問題

スコープとは何ですか?

1.各属性値の
コンパイルの意味を列挙します。すべてのステージに適用可能なデフォルト値がプロジェクトにパッケージ化されます。
コンパイルと同様に、JDK、コンテナ、またはユーザーがこの依存関係を提供することが期待されています。
ランタイムは、JDBCドライバーなどのランタイムでのみ使用され、操作とテストに適しています。
テスト、テスト中にのみ使用され、テストコードをコンパイルして実行します。プロジェクトではリリースされません。
システムは、提供されたものと同様に、依存関係を含むjarを明示的に提供する必要があります。Mavenはそれをリポジトリで検索しません

Gradleバージョンの依存関係を再生するには?

参考資料

https://www.cnblogs.com/lykbk/p/erwerwerwerwerwerwe.html

https://blog.csdn.net/zy103118/article/details/84442623

元の記事を33件公開しました 賞賛されました37 再生回数110,000回

おすすめ

転載: blog.csdn.net/hagle_wang/article/details/105391250