GradleラッパーをVCSにコミットする必要があるのはなぜですか？

Gradleのドキュメントから： https : //docs.gradle.org/current/dsl/org.gradle.api.tasks.wrapper.Wrapper.html

このタスクによって生成されたスクリプトは、バージョン管理システムにコミットすることを目的としています。このタスクは、VCSにもコミットする必要がある小さなgradle-wrapper.jarブートストラップJARファイルとプロパティファイルも生成します。スクリプトはこのJARに委任します。

From： ソース管理下にあるべきではないものは何ですか？

Generated filesVCSに入れるべきではないと思います。

いつgradlew、gradle/gradle-wrapper.jar必要ですか？

なぜ、保管しないgradle versionでbuild.gradleファイルを？

Gradleラッパーの要点は、Gradleをインストールしたことがなく、動作方法も知らずに、どこからダウンロードするか、どのバージョンか、VCSからプロジェクトを複製してGradlewスクリプトを実行できるようにすることです。を含み、追加のステップなしでプロジェクトをビルドします。

build.gradleファイル内のGradleバージョン番号しかなかった場合は、GradleバージョンXをURL Yからダウンロードしてインストールする必要があることをすべてのユーザーに説明するREADMEが必要であり、バージョンが増加するたびにそれを実行する必要があります。

Gradleラッパーの要点は、Gradleをインストールしたことがなくてもできるようにするためです

JDKについても同じことが言えますが、それもコミットしますか？すべての依存ライブラリもコミットしますか？

新しいバージョンがリリースされたら、依存関係を継続的にアップグレードする必要があります。セキュリティおよびその他のバグ修正を取得する。そして、はるかに遅れた場合、それを再度最新の状態にするには、非常に時間のかかる作業になる可能性があるためです。

Gradleラッパーが新しいリリースごとに増分され、コミットされると、リポジトリは非常に大きくなります。クローンがすべてのバージョンのすべてのバージョンをダウンロードする分散VCSで作業する場合、問題は明白です。

、そしてそれがどのように機能するかさえ知らずに

ラッパーをダウンロードしてビルドに使用するビルドスクリプトを作成します。誰もがスクリプトがどのように機能するかを知る必要はありません。プロジェクトを実行してビルドすることに同意する必要があります。

、ダウンロード元、バージョン

task wrapper(type: Wrapper) {
 gradleVersion = 'X.X' 
}

その後

gradle wrapper

正しいバージョンをダウンロードするには。

、VCSからプロジェクトのクローンを作成し、それに含まれるgradlewスクリプトを実行し、追加の手順なしでプロジェクトをビルドします。

上記の手順で解決しました。Gradleラッパーのダウンロードは、他の依存関係のダウンロードと同じです。スクリプトは、現在のGradleラッパーをチェックし、新しいバージョンがある場合にのみそれをダウンロードするのが賢明です。

開発者がこれまでにGradleを使用したことがなく、おそらくプロジェクトがGradleでビルドされていることを知らない場合。次に、「gradlew build」を実行するよりも、「build.sh」を実行する方がわかりやすいでしょう。

build.gradleファイルにGradleバージョン番号しかなかった場合は、インストールされているURL YからGradleバージョンXをダウンロードする必要があることを全員に説明するREADMEが必要です。

いいえ、READMEは必要ありません。1つでも構いませんが、私たちは開発者であり、可能な限り自動化する必要があります。スクリプトを作成することをお勧めします。

そして、あなたはバージョンがインクリメントされるたびにそれをしなければならないでしょう。

開発者が正しいプロセスは次のとおりであることに同意した場合：

1. クローンレポ
2. ビルドスクリプトを実行する

その後、最新のGradleラッパーにアップグレードしても問題ありません。前回の実行以降にバージョンが増加している場合、スクリプトは新しいバージョンをダウンロードできます。

簡単なアプローチをお勧めします。

プロジェクトのREADMEに、インストール手順が必要であることを文書化します。

gradle wrapper --gradle-version 3.3

これはGradle 2.4以降で動作します。これにより、「build.gradle」に専用のタスクを追加する必要なく、ラッパーが作成されます。

このオプションでは、バージョン管理のためにこれらのファイル/フォルダーを無視（チェックインしない）します。

• ./gradle
• Gradlew
• gradlew.bat

主な利点は、ダウンロードしたファイルをソース管理にチェックインする必要がないことです。インストールに追加の手順が1つ必要です。価値があると思います。

「プロジェクト」とは何ですか？

おそらく、ビルドスクリプトを除外するこのイディオムの技術的な定義があります。ただし、この定義を受け入れる場合は、「プロジェクト」がバージョン管理に必要なすべてのものではないことを示す必要があります。

しかし、我々は「プロジェクト」と言う場合であるすべてのもの、あなたが行っています。次に、それをVCSに含める必要があります。

これは非常に理論的であり、開発作業の場合には実用的ではない可能性があります。したがって、「プロジェクトは、直接編集する必要のあるすべてのファイル（またはフォルダー）です」に変更します。

^{「直接」は「間接的ではない」を意味し、「間接的」は別のファイルを編集することを意味し、エフェクトはこのファイルに反映されます。}

したがって、OPが言った（そしてここで言った）のと同じ結果になります。

生成されたファイルはVCSにあるべきではないと思います。

はい。まだ作成していないためです。したがって、2番目の定義によれば、これらは「プロジェクト」の一部ではありません。

これらのファイルの結果は何ですか：

• build.gradle：はい。それを編集する必要があります。私たちの作品はバージョン管理されるべきです。

  注：編集する場所に違いはありません。テキストエディター環境またはプロジェクト構造 GUI環境のどちらにあるか。とにかくあなたはそれを直接やっています！

• gradle-wrapper.properties：はい。このファイルで少なくともGradleのバージョンを確認する必要があります。

• gradle -wrapper.jarとgradlew [.bat]：この瞬間まで、私はどの開発作業でもそれらを作成または編集していません。したがって、答えは「いいえ」です。そうした場合、その作業でのあなた（および編集した同じファイル）についての答えは「はい」です。

の 最新のケースに関する重要な注意事項は、あなたのレポのクローンユーザーで、このコマンドを実行する必要があるレポの<root-directory>に自動生成ラッパーファイル：

> gradle wrapper --gradle-version=$v --distribution-type=$distType

$vそしてgradle-wrapper.properties$distTypeから決定されます：

distributionUrl=https\://services.gradle.org/distributions/gradle-{$v}-{$distType}.zip

詳細については、https：//gradle.org/install/を参照してください。

gradle 実行可能です bin/gradle[.bat]ローカル配布されています。ローカル配布がリポジトリで決定されたものと同じである必要はありません。後にラッパーファイルは、その後、作成したgradlew[.bat]（ローカルに存在していない場合）、自動的に決定したのGradleディストリビューションをダウンロードすることができます。次に、彼/彼女はおそらくgradle、上記の手順を使用して、（ダウンロードしたディストリビューションの）新しい実行可能ファイルを使用してラッパーファイルを再生成する必要があります。

注：上記の手順では、ユーザーが少なくともローカルに 1つの Gradleディストリビューションを（例：）~/.gradle/wrapper/dists/gradle-4.10-bin/bg6py687nqv2mbe6e1hdtk57h/gradle-4.10。それはほとんどすべての実際のケースをカバーします。しかし、ユーザーがまだディストリビューションを持っていない場合はどうなりますか？

.propertiesファイル内のURLを使用して手動でダウンロードできます。しかし、彼/彼女がそれをパスに見つけなかった場合、ラッパーが予期、ラッパーはそれを再びダウンロードします！予想される経路は完全に予測可能ですが、対象外です（最も複雑な部分については、こちらを参照してください）。

より簡単な（しかし汚い）方法もあります。たとえば、ラッパーファイル（.propertiesファイルを除く）を他のローカル/リモートリポジトリから自分のリポジトリにコピーして、自分のリポジトリで実行できgradlewます。適切なディストリビューションが自動的にダウンロードされます。

Gradle docsによると、開発者がGradleラッパーを利用できるようにすることはGradleアプローチの一部であるため、gradle-wrapper.jarVCSへの追加が期待されています。

Wrapperファイルを他の開発者や実行環境で利用できるようにするには、それらをバージョン管理にチェックインする必要があります。JARファイルを含むすべてのラッパーファイルのサイズは非常に小さいです。JARファイルをバージョン管理に追加する必要があります。一部の組織では、プロジェクトがバイナリファイルをバージョン管理に提出することを許可していません。現時点では、このアプローチに代わる選択肢はありません。

古い質問、新鮮な答え。Gradleを頻繁にアップグレードしない場合（ほとんどの場合はそうではありません）、VCSにコミットすることをお勧めします。そして、私にとっての主な理由は、CIサーバーのビルド速度を上げることです。現在、ほとんどのプロジェクトはCIサーバーによってビルドおよびインストールされており、毎回異なるサーバーインスタンスを使用しています。

コミットしない場合、CIサーバーはビルドごとにjarをダウンロードし、ビルド時間が大幅に増加します。この問題を処理する方法は他にもありますが、維持するのが最も簡単だと思います。