Gradle Wrapper가 VCS에 커밋되어야하는 이유는 무엇입니까?

Gradle Wrapper가 VCS에 커밋되어야하는 이유는 무엇입니까?

---

Gradle의 설명서에서 : https://docs.gradle.org/current/dsl/org.gradle.api.tasks.wrapper.Wrapper.html

이 태스크에서 생성 된 스크립트는 버전 제어 시스템에 적용되도록 설계되었습니다. 이 작업은 또한 작은 gradle-wrapper.jar 부트 스트랩 JAR 파일 및 VCS에 커밋해야하는 특성 파일을 생성합니다. 스크립트는이 JAR에 위임합니다.

From : 소스 제어하에 있어서는 안되는 것은 무엇입니까?

Generated filesVCS에 있어서는 안된다고 생각 합니다.

언제 gradlew그리고 gradle/gradle-wrapper.jar필요합니까?

왜이 아닌 저장 gradle version에 build.gradle파일?

---

gradle wrapper의 요점은 gradle을 설치하지 않고 작동 방식을 알지 않고도 VCS에서 프로젝트를 복제하고 gradlew 스크립트를 실행할 수있는 버전을 다운로드 할 수있는 버전입니다. 추가 단계없이 프로젝트를 포함하고 빌드합니다.

build.gradle 파일의 gradle 버전 번호 만 있으면 gradle 버전 X를 URL Y에서 다운로드하여 설치해야한다는 점을 설명하는 README가 필요하며 버전이 증가 할 때마다 수행해야합니다.

---

gradle 래퍼의 요점은 gradle을 설치하지 않고도 가능합니다.

같은 주장이 JDK에도 적용됩니다. 또한 커밋 하시겠습니까? 또한 모든 의존성 라이브러리를 커밋합니까?

새 버전이 릴리스 될 때 종속성을 지속적으로 업그레이드해야합니다. 보안 및 기타 버그 수정 그리고 당신이 훨씬 뒤에 도착하면 다시 최신 정보를 얻는 데 시간이 많이 걸리는 작업이 될 수 있습니다.

새로운 릴리스마다 gradle wrapper가 증가하고 커밋되면 repo가 ​​매우 커집니다. 클론이 모든 버전의 모든 버전을 다운로드하는 분산 VCS로 작업 할 때 문제가 발생합니다.

작동 방식을 몰라도

랩퍼를 다운로드하고이를 사용하여 빌드하는 빌드 스크립트를 작성하십시오. 모든 사람이 스크립트의 작동 방식을 알 필요는 없으며 프로젝트를 실행하여 빌드한다는 데 동의해야합니다.

, 다운로드 위치, 버전

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

그리고

gradle wrapper

올바른 버전을 다운로드하려면

VCS에서 프로젝트를 복제하고 포함 된 gradlew 스크립트를 실행하고 추가 단계없이 프로젝트를 빌드합니다.

위의 단계로 해결되었습니다. gradle wrapper를 다운로드하는 것은 다른 종속성을 다운로드하는 것과 다르지 않습니다. 스크립트는 현행 gradle 래퍼를 확인하고 새 버전이있는 경우에만 다운로드하는 것이 현명합니다.

개발자가 이전에 Gradle을 사용한 적이없고 Gradle을 사용하여 프로젝트가 빌드되었는지 알지 못하는 경우. 그런 다음 "gradlew build"를 실행하는 것과 비교하여 "build.sh"를 실행하는 것이 더 분명합니다.

build.gradle 파일의 gradle 버전 번호 만 있으면 gradle 버전 X를 설치된 URL Y에서 다운로드해야한다고 설명하는 README가 필요합니다.

아니요, README가 필요하지 않습니다. 하나는 가질 수 있지만 우리는 개발자이며 가능한 한 자동화해야합니다. 스크립트를 작성하는 것이 좋습니다.

버전이 증가 할 때마다해야합니다.

개발자가 올바른 프로세스에 동의하는 경우 :

1. 복제 저장소
2. 빌드 스크립트 실행

그런 다음 최신 gradle 래퍼로 업그레이드해도 아무런 문제가 없습니다. 마지막 실행 이후에 버전이 증가하면 스크립트가 새 버전을 다운로드 할 수 있습니다.

---

간단한 접근 방식을 추천하고 싶습니다.

프로젝트의 README에서 설치 단계가 필요하다는 것을 문서화하십시오.

gradle wrapper --gradle-version 3.3

Gradle 2.4 이상에서 작동합니다. "build.gradle"에 전용 작업을 추가 할 필요없이 래퍼를 만듭니다.

이 옵션을 사용하면 버전 제어를 위해 다음 파일 / 폴더를 무시하십시오 (체크인하지 마십시오).

• ./gradle
• gradlew
• gradlew.bat

주요 이점은 소스 제어를 위해 다운로드 한 파일을 체크인 할 필요가 없다는 것입니다. 설치시 추가 단계가 필요합니다. 그만한 가치가 있다고 생각합니다.

---

"프로젝트"는 무엇입니까?

빌드 스크립트를 제외하고이 관용구에 대한 기술적 정의가있을 수 있습니다. 그러나이 정의를 받아들이면 "프로젝트"가 버전 관리에 필요한 모든 것이 아니라고 말해야합니다!

그러나 우리는 "프로젝트"를 말한다면이며 모든 것을 당신이 수행했다 . 그런 다음 VCS 에만 포함시켜야한다고 말할 수 있습니다 .

이것은 매우 이론적이며 개발 작업의 경우 실용적이지 않을 수 있습니다. 따라서 " 프로젝트는 파일을 직접 편집해야하는 모든 파일 (또는 폴더) 입니다 "로 변경합니다 .

^{"directly" means "not indirectly" and "indirectly" means by editing another file and then an effect will be reflected into this file.}

So we reach the same that OP said (and is said here):

I think Generated files should not be in the VCS.

Yes. Because you hadn't created them. So they are not part of "your project" according to the second definition.

---

What is the result about these files:

• build.gradle: Yes. We need to edit it. Our works should be versioned.

  Note: There is no difference where you edit it. Whether in your text editor environment or in Project Structure GUI environment. Anyway you doing it directly!

• gradle-wrapper.properties: Yes. We need to at least determine Gradle version in this file.

• gradle-wrapper.jar and gradlew[.bat]: I haven't created or edited them in any of my development works, till this moment! So the answer is "No". If you have done so, the answer is "Yes" about you at that work (and about the same file you edited).

---

The important note about the latest case is the user who clones your repo, needs to execute this command on repo's <root-directory> to auto-generate wrapper files:

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

$v and $distType are determined from gradle-wrapper.properties:

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

See https://gradle.org/install/ for more information.

gradle executable is bin/gradle[.bat] in local distribution. It's not required that local distribution be same as that determined in the repo. After wrapper files created then gradlew[.bat] can download determined Gradle distribution automatically (if not exists locally). Then he/she probably must regenerate wrapper files using new gradle executable (in downloaded distribution) using above instructions.

---

Note: In the above instructions, supposed the user has at least one Gradle distribution locally (e.g. ~/.gradle/wrapper/dists/gradle-4.10-bin/bg6py687nqv2mbe6e1hdtk57h/gradle-4.10). It covers almost all real cases. But what happens if the user hasn't any distribution already?

He/She can download it manually using the URL in .properties file. But if he/she doesn't locate it in the path that the wrapper expected, the wrapper will download it again! The expected path is completely predictable but is out of the subject (see here for the most complex part).

There are also some easier (but dirty) ways. For example, he/she can copy wrapper files (except .properties file) from any other local/remote repository to his/her repository and then run gradlew on his/her repository. It will automatically download the suitable distribution.

참고URL : https://stackoverflow.com/questions/20348451/why-should-the-gradle-wrapper-be-committed-to-vcs