Gradleの目的は何ですか?質問する

Gradleの目的は何ですか?質問する

Android Studio 0.4.0 のコンテキストで Gradle (プラグイン v 0.7) の背後にある概念を理解するのに少し助けが必要です。私はこれまで Gradle を使用したことがなく、問題ばかり起こしています。十分に理解していないため、その目的や利点がわかりません。

いくつか具体的な質問があります

  1. これらの依存関係とは何ですか? ネイティブにサポートされているはずの API 11+ をターゲットにした、ナビゲーション ドロワーを備えたシンプルなアプリを作成しています。どのような依存関係を使用できますか?

  2. Gradle ラッパーとは何ですか? 完成したアプリケーションにどのような変更が加えられますか?

  3. なぜ Gradle は常にオンラインである必要があるのでしょうか? 仕事中は、個人のラップトップでインターネットにアクセスできません。インターネットにアクセスできないと Gradle が一部のリソースを解決できないため、アプリを実行したりテストしたりできない状態になっています。

  4. Gradle が Groovy を使用することはなぜ重要なのでしょうか? インターネットで調べてみたところ、Gradle は Groovy が好まれる傾向があるようですが、Groovy がなぜ重要なのか、Android アプリで何を行うのかについては説明されていないことが多いようです。

情報が単純すぎるか複雑すぎる傾向があるため、中級プログラマーにとっては難しい場合があります。私の具体的な質問とは別に、提供できる追加情報があれば役立ちます。私は、Gradle と、同じことができる他のツールの長所と短所を議論するつもりはありません。情報に基づいた決定を下せるように、Gradle とその使用法についてもっと知りたいだけです。

ありがとう

ベストアンサー1

質問の中には、ビルド ツールが一般的になぜ良いものなのかを語る一般的な質問もあります。Gradle に特化している質問もあります。他の人の細かい用語を避けながら、両方のカテゴリについてできるだけ簡潔に説明しようと思います。

Maven、Gradle、SBT、Leiningenなどのビルドツールは、手動で実行する必要があるタスク、つまり「手動で自動化」するタスクを自動化するのに役立ちます。後者は、私がAntで行っていたこと、つまりコンパイル、実行、Javadocの生成などのカスタムタスクを記述して、将来的にタスクを自動化できるようにすることを説明しています。Mavenによって最初に定義され、その後他のツールで採用された規則(ソースをソース/メイン/java) を使用すると、これが可能になります。規則に従えば、ビルド ツールは最小限の追加作業で、コンパイル、実行、Javadoc の生成、テストなど、あらゆる操作を実行できます。

さて、質問に移ります(順番に):

  1. ビルド ツールのもう 1 つの重要な機能は、ビルド間で一貫した方法で依存関係を管理することにより、「jar 地獄」を軽減することです。必要な Apache Commons、Google Guava、Spring、Jackson のバージョン (またはバージョンの範囲) を指定するだけで、ビルド ツールがそれらをダウンロードし、クラスパスとビルド内 (war ファイルなど) に適切な場所に配置してくれます。スコープも定義できます。たとえば、この依存関係はコンパイル時に使用可能にし、他の依存関係は実行時にのみ使用可能にしたいとします。明示的に提供する必要があるのか​​、それとも使用可能になるのか、といったことです。
  2. これはGradle特有のものです。ここGradle ラッパーは、チームが手動で Gradle をインストールしなくても一貫性を保ちながら Gradle を実行できるようにしてくれます。全員が同じバージョンを使用します。一度設定してしまえば、もう気にする必要はなく、使用したい Gradle タスクはすべてラッパー経由で利用できるので、ラッパーの存在を気にする必要もありません。Gradle を直接インストールして直接実行することもできますが、その意味がほとんどわかりません。
  3. これは一般的なことです。先ほど依存関係の管理について触れました。これらの依存関係を取得するには、ビルドツールがMaven Centralまたはサードパーティのリポジトリから入手できるオンラインに接続する必要があります。他のMavenでも採用されているもう1つのMavenの革新は、リポジトリ管理、コンパイルされた成果物は規則に従ってリポジトリに公開され、他のプロジェクトで使用できるようになります。通常、この点は気にする必要はありません。ツールに特定の依存関係が必要であることを伝えるだけで、誰もが規則に従っているため、ツールはそれを取得する方法を知っています。インターネットにアクセスできない場合 (これは私にとって非常によくあることです) のオプションは、オンラインのときにすべての依存関係を取得し、オプションで Nexus や Artifactory などのローカル Maven リポジトリを設定して、それらの成果物を公開することです。次に、ビルド ツールに、そこと Maven Central などを検索するように指示します。
  4. Maven は XML で設定され、当時はそれがとてもクールに思えました。しかし、その結果が 2 つあります。1 つは設定が非常に冗長になることです。もう 1 つは、カスタム処理が難しくなることです。すべてを XML で宣言的に行う必要があり、多くの人がこれを面倒だと感じています。プラグインを XML で設定するか、独自のプラグインを書いて、Maven が理解できる方法でラップし、XML で設定できるようにします。コードでカスタム ビルドを行う方がはるかに簡単で強力です。Gradle が Groovy を選択したのは、Groovy は優れた DSL を作成し、Maven から来た Java 開発者にとって非常に簡単に習得できるためです。SBT が Scala を選択し、Leiningen が Clojure を選択したのは、これらのビルド ツールがそれらの言語/プラットフォームを対象としているためです。そのため、たとえば Scala 開発者は SBT を使用するために DSL 以外に何か新しいことを学ぶ必要はありません。しかし、より広い視点で見ると、XML ではなくコードに依存することには多くの利点があります。

お役に立てれば幸いです。

おすすめ記事