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 .

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

^{"직접"은 "간접적으로"가 아닌 것을 의미하고 "간접적으로"는 다른 파일을 편집하여이 파일에 효과가 반영됨을 의미합니다 .}

따라서 OP가 말한 것과 동일하게 도달합니다 ( 여기서 설명 ).

생성 된 파일은 VCS에 없어야한다고 생각합니다.

예. 당신 이 그들을 만들지 않았기 때문에 . 따라서 두 번째 정의에 따라 "프로젝트"의 일부가 아닙니다.

이 파일들에 대한 결과는 무엇입니까?

• build.gradle : 예. 편집해야합니다. 우리의 작품은 버전 화되어야합니다.

  참고 : 편집 위치에는 차이가 없습니다. 텍스트 편집기 환경 또는 프로젝트 구조 GUI 환경에서. 어쨌든 당신 은 그것을 직접 하고 있습니다 !

• gradle-wrapper.properties : 예. 이 파일에서 최소한 Gradle 버전을 결정해야합니다.

• gradle-wrapper.jar and gradlew [.bat] : 나는 지금까지 내 개발 작업에서 그것들을 만들거나 편집하지 않았다! 답은 "아니오"입니다. 그렇게 한 경우 해당 작업에서 사용자에 대해 "예"로 (그리고 편집 한 동일한 파일에 대한) 대답이됩니다.

최신 사건에 대해 중요한 점은 당신의 repo를 복제합니다 사용자가에서이 명령을 실행 할 필요가있다 REPO의<root-directory> 에 자동 생성을 파일 랩퍼 :

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

$v과 $distType에서 결정됩니다 gradle-wrapper.properties :

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

자세한 내용은 https://gradle.org/install/ 을 참조하십시오.

gradle실행 파일은 bin/gradle[.bat]로컬 배포에 있습니다. 로컬 배포가 리포지토리에서 결정된 배포와 동일 할 필요는 없습니다. 후 래퍼 파일 다음 생성은 gradlew[.bat](로컬에 존재하는 경우) 자동으로 Gradle을 분포를 결정 다운로드 할 수 있습니다. 그런 다음 gradle위의 지침을 사용 하여 새 다운로드 파일 (다운로드 한 배포판)을 사용 하여 래퍼 파일을 재생성해야합니다 .

참고 : 사용자 가정 위의 지침에서는이 적어도 하나의 로컬 Gradle을 배포 (예를 ~/.gradle/wrapper/dists/gradle-4.10-bin/bg6py687nqv2mbe6e1hdtk57h/gradle-4.10). 거의 모든 실제 사례를 다룹니다. 그러나 사용자가 아직 배포를하지 않은 경우 어떻게됩니까?

.properties파일 의 URL을 사용하여 수동으로 다운로드 할 수 있습니다 . 그러나 래퍼가 예상 한 경로에서 찾지 못하면 래퍼 가 다시 다운로드합니다! 예상 경로는 완전히 예측 가능하지만 주제를 벗어났습니다 ( 가장 복잡한 부분 은 여기 참조 ).

더 쉬운 (더러운) 방법도 있습니다. 예를 들어, 다른 로컬 / 원격 리포지토리에서 래퍼 파일 ( .properties파일 제외 )을 다른 리포지토리로 복사 한 다음 리포지토리에서 실행할 gradlew수 있습니다. 적절한 배포판을 자동으로 다운로드합니다.

Gradle docs 에 따르면 개발자가 Gradle Wrapper를 사용할 수있게 하는 gradle-wrapper.jar것은 VCS에 추가 될 것으로 예상 됩니다.

래퍼 파일을 다른 개발자 및 실행 환경에서 사용할 수있게하려면 파일 제어를 버전 제어로 확인해야합니다. JAR 파일을 포함한 모든 랩퍼 파일의 크기는 매우 작습니다. 버전 제어에 JAR 파일 추가가 예상됩니다. 일부 조직에서는 프로젝트가 이진 파일을 버전 관리에 제출하도록 허용하지 않습니다. 현재이 접근법에는 다른 대안이 없습니다.

오래된 질문, 신선한 답변. gradle을 자주 업그레이드하지 않으면 (대부분은 그렇지 않습니다) VCS에 커밋하는 것이 좋습니다. 그리고 주된 이유는 CI 서버의 빌드 속도를 높이는 것입니다. 오늘날 대부분의 프로젝트는 매번 다른 서버 인스턴스 인 CI 서버에 의해 구축되고 설치됩니다.

커밋하지 않으면 CI 서버는 모든 빌드마다 jar 파일을 다운로드하여 빌드 시간을 크게 증가시킵니다. 이 문제를 처리하는 다른 방법이 있지만이 방법을 유지 관리하는 것이 가장 쉽다는 것을 알았습니다.