ANT、Maven、Gradle に入る前に、まずこれらに関するいくつかのことを理解する必要があります。 一般に、依存関係は、何かがそれ自身を実行するために別のものを必要とする場合を指します。 簡単に言えば、’A’ がその正常な実行のために ‘B’ を必要とする場合、’A’ は ‘B’ に依存しているということです。 ソフトウェアの世界では、依存性とは、あなたのアプリケーションが正常に実行されるために必要とするあらゆるものを指します。 例えば、zuul、hystrix、lombok、jdbc などです。
最初は、次のようにして依存関係を管理していました:
- インターネットから必要なライブラリの jar ファイルを手動でダウンロードして、プロジェクトに追加すること。
これらのツールを使用する前に直面した問題:
- インターネットから手動でダウンロードして依存関係を追加するのは非常に疲れる作業です。
- インターネット上で外部ソースの URL が変更されると、スクリプトが失敗するかもしれません。
ビルドツール:アプリケーションに必要な依存関係を解決し、管理します。 ソースコードから実行可能なアプリケーションの作成を自動化します。 ビルドには、コードをコンパイル、リンク、および使用可能または実行可能な形式にパッケージ化することが含まれます。 ビルドの自動化には、
- 依存関係のダウンロード
- ソースコードをバイナリコードにコンパイル
- そのバイナリコードをパッケージ化
- テストの実行
- 生産システムへのデプロイ
Java における依存関係の管理およびビルドツールがあります。
- ANT + Ivy (2000/2004)
- Maven (2004)
- Gradle (2012)
Apache ANT (Another Neat Tool) は Apache によるオープンソース プロジェクトで、2000 年にリリースされました。 Javaアプリケーションのビルドプロセスを自動化するために使用されるjavaライブラリです。 また、非Javaアプリケーションのビルドにも利用できる。 慣習よりも構成」という原則に従っている。 Antでは、ビルドプロセスの異なる段階を「ターゲット」と呼びます。 ANTのビルドファイルはXMLで記述され、慣習的に “build.xml “と呼ばれます。 プロジェクト、ターゲット、タスクの3つの要素を含んでいます。 各ビルドファイルには、1つのプロジェクトが含まれます。 build.xmlの中のあらゆるものはproject要素の下にあります。 プロジェクトには、少なくとも1つのターゲット(デフォルト)が含まれます。 ターゲットは、その中にタスクのセットを含み、ビルドプロセスの特定の状態を定義する。 タスクは、実行可能なコード片です。
Attributes of Project:
- Name.Name.Nodes.は、各ノードに属性を関連付けることができます。 プロジェクトの名前。
- Basedir: プロジェクトのルートフォルダーで、オプションです。 ビルドのデフォルトターゲットです。 プロジェクトは1つまたは複数のターゲットを持つことができます。
ターゲットの属性:
- 名前: ターゲットの名前。
- 説明。 ターゲットに関する説明。
- Depends: このターゲットが依存するすべてのターゲットのリスト(カンマで区切られています).
- If: ターゲットが実行されるのは、この属性が真である場合です。
Build.xml の例:
<?xml version="1.0"?>
<project>
<target name="hello">
<echo>Hello, World</echo>
</target>
</project>Ant + Ivy で依存関係を追加:
<dependency org="org.projectlombok" name="lombok" rev="1.18.10"/>
Ant の最大の利点はその柔軟性にあります。 Antは開発者にコーディング規約やプロジェクト構造を押し付けません。 その結果、Antは開発者がすべてのコマンドを自分で書くことを要求し、時にはビルドファイルが大きくなり、保守が大変になることを意味します。 当初、Antは依存性管理のサポートを内蔵していませんでした。
Apache Maven
2004年にリリースされた依存関係管理およびビルド自動化ツールです。 XMLを使い続けているが、「設定より規約」という原則に従うことで欠点を克服している。 慣例に依存し、あらかじめ定義されたコマンド(ゴール)を提供する。 ビルドと依存関係の管理命令を含む設定ファイルは慣習的に “pom.xml” と呼ばれ、プロジェクトのルート フォルダに存在します。
Maven エンジンには pom.xml とプロジェクトを入力として受け取ります。 pom.xml ファイルを読み取り、その中に記載されている依存関係を jar ファイルとしてローカル リポジトリにダウンロードします。 そして、ライフサイクル、ビルドフェーズ、プラグインを実行します。
pom.xml の例:
pom.xml ファイル内のいくつかの重要なタグ:
- groupId.Id。 プロジェクトが属する組織を表します。
- artifactId: プロジェクトの名前です。
- version: プロジェクトのバージョンを表します。
- パッケージング。 例えば、jar、war.
Add dependency in maven:
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.10</version>
</dependency>Maven repository:
リポジトリとは、すべてのパッケージされたjarファイルが独自のpomファイルとともに存在するディレクトリのことである。 これらの pom ファイルは、そのプロジェクトの外部依存関係を含んでいます。 この方法で maven は、必要な依存関係がすべてローカルリポジトリに存在するようになるまで、プロジェクトの依存関係の依存関係を再帰的にダウンロードします。 maven には 3 種類のリポジトリがあります:
- ローカルリポジトリ:
- 組織レベル/リモートリポジトリ: 開発者のマシン自体に存在するリポジトリです。
- セントラルリポジトリ:組織内に存在するリポジトリです。
- セントラルリポジトリ:インターネット上のリポジトリで、maven コミュニティによって作成および保守されています。
プロジェクトの pom.xml ファイルで依存関係が指定されると、maven はローカルリポジトリでそれを探します。 そこで見つからない場合、リモート/org ワイド リポジトリで探します。
Mavenは厳密なプロジェクト構造を規定しますが、Antはそこでも柔軟性を提供します。
Maven の欠点:
- Dependency management doesn’t handle conflicts well between different versions of the same library.これは、同じライブラリの異なるバージョン間の衝突をうまく処理しません。
- 目標のカスタマイズが難しい。
Gradle
2012年にリリースされたオープンソースの依存性管理およびビルド自動化ツールです。 Apache AntとApache Mavenの良いところを組み合わせてビルドし、XMLの代わりにドメイン固有言語(Groovyベース)を使用しています。 Antから柔軟性を、Mavenからそのライフサイクルを採用した。 また、”Convention over Configuration “の原則に則っている。 依存関係を取得するために、MavenとIvyリポジトリをサポートしています。 設定ファイルは、慣習的に「build.gradle」と呼ばれ、プロジェクトのルートフォルダ内に存在する。 Antの「ターゲット」やMavenの「フェーズ」に対して、Gradleはビルドステップを「タスク」と命名している。 Google は Android OS のデフォルトビルドツールとして Gradle を採用した。
Gradle は XML を使用しない。 その代わり、Groovy (JVM言語の1つ) に基づいた独自のドメイン固有言語を持っていた。 その結果、Gradle のビルドスクリプトは Ant や Maven 用に書かれたものよりもはるかに短く、明確である傾向があります。 Gradle.
Gradle configurations
- の実装では、定型的なコードの量ははるかに少なくなります。 これは、消費者のコンパイル時に公開したくない依存関係を宣言するために使用されます。
- api: API の一部である依存関係、つまり、明示的にコンシューマに公開したい依存関係を宣言するために使用されます。
- compileOnly。 コンパイル時にのみ利用可能で、実行時には必要ない依存関係を宣言することができます。 この設定の使用例としては、Lombok のようなアノテーション プロセッサで、コンパイル時にバイトコードを変更するものがあります。 コンパイル後はもう必要ないので、依存関係は実行時に利用できません。
- runtimeOnly。 コンパイル時には必要ないが、実行時には利用可能になる依存関係を宣言することができます。 例として、SLF4J では
implementation
設定にslf4j-api
を、runtimeOnly
設定にその API の実装 (slf4j-log4j12
やlogback-classic
) を含めます。 - testImplementation.Parents>:コンパイル時には必要ないが、実行時には利用できる依存関係を宣言します。
implementation
と似ていますが、testImplementation
で宣言された依存関係は、テストのコンパイル時と実行時にのみ利用可能です。 JUnit や Mockito など、テストでのみ必要となり、実稼働コードでは利用できないようなテストフレームワークへの依存を宣言するために使用できます。 - testCompileOnly:
compileOnly
と似ていますが、testCompileOnly
で宣言された依存関係はテストのコンパイル時のみ利用可能で、実行時には利用できません。 - testRuntimeOnly:
runtimeOnly
と似ていますが、testRuntimeOnly
で宣言された依存関係は、コンパイル時ではなく、テストの実行時にのみ利用可能です。
Projects and tasks in Gradle
すべての Gradle ビルドは 1 つまたは複数のプロジェクトで構成されています。 各プロジェクトはタスクのセットで構成されます。 各タスクは、ビルドが実行する単一のピースを表します。たとえば、JavaDoc を生成する、リポジトリにいくつかのアーカイブを公開するなどです。
build.gradle 例
Gradleリポジトリ:
Gradleでの「エイリアス」は、プロジェクトのビルドにMavenリポジトリを追加する際に使用されます。 これらのエイリアスは次のとおりです:
- mavenCentral()。 このエイリアスは、中央の Maven 2 リポジトリからフェッチされる依存関係を表します。 このエイリアスは、Bintray の JCenter Maven リポジトリから取得される依存関係のために表します。
例: プロジェクトで中央の Maven リポジトリを追加し、次のコード スニペットを ‘build.gradle’ ファイルに追加します:
repositories {
mavenCentral()
}Add dependency in Gradle:
compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
利点:
- これは、移行依存性をうまく扱うことができる。 競合する推移的依存関係がプロジェクトに存在する場合、それを解決するために、それは依存関係の最新バージョンを選択します。 たとえば、依存関係 ‘A’ は内部的にバージョン 2.0 の依存関係 ‘C’ を必要とし、依存関係 ‘B’ は内部的にバージョン 3.0 の依存関係 ‘C’ を必要とします。
- Gradle は XML ではなく Groovy をベースにしたドメイン固有の言語を使用しているため、設定ファイルのサイズは小さく、よりクリーンです。
- Gradle はインクリメンタル・ビルドの概念を使用しており、タスクの入力と出力を追跡して必要なものだけを実行し、可能な場合は変更のあったファイルだけを処理して作業を回避するので、maven より速く実行されます。