ทำไม Gradle Wrapper ถึงมุ่งมั่นที่จะ VCS?

จากเอกสารของ Gradle: https://docs.gradle.org/current/dsl/org.gradle.api.tasks.wrapper.Wrapper.html

สคริปต์ที่สร้างขึ้นโดยงานนี้มีวัตถุประสงค์เพื่อมุ่งมั่นกับระบบควบคุมเวอร์ชันของคุณ ภารกิจนี้ยังสร้างไฟล์ gradst-wrapper.jar bootstrap JAR และไฟล์คุณสมบัติที่ควรถูกกำหนดให้กับ VCS ของคุณด้วย สคริปต์มอบหมายให้ JAR นี้

จาก: สิ่งที่ไม่ควรอยู่ภายใต้การควบคุมของแหล่งที่มา?

ฉันคิดว่าGenerated filesไม่ควรอยู่ใน VCS

เมื่อใดgradlewและgradle/gradle-wrapper.jarจำเป็นหรือไม่

ทำไมไม่จัดเก็บgradle versionในbuild.gradleไฟล์?

เนื่องจากจุดรวมของ wrapper gradle นั้นสามารถทำได้โดยไม่ต้องติดตั้ง gradle และไม่เคยรู้เลยว่ามันทำงานยังไง, จะดาวน์โหลดจากที่ไหน, เวอร์ชั่นใด, เพื่อโคลนโปรเจ็กต์จาก VCS, เพื่อรันสคริปต์ gradlew มีและเพื่อสร้างโครงการโดยไม่มีขั้นตอนเพิ่มเติมใด ๆ

หากสิ่งที่คุณมีคือหมายเลขรุ่น gradle ในไฟล์ build.gradle คุณจะต้อง README อธิบายทุกคนว่าต้องดาวน์โหลดรุ่น gradle จาก URL Y และติดตั้งและคุณจะต้องทำทุกครั้งที่มีรุ่นเพิ่มขึ้น

เพราะจุดรวมของ wrapper gradle จะสามารถทำได้โดยไม่ต้องติดตั้ง gradle

อาร์กิวเมนต์เดียวกันนั้นเกิดขึ้นกับ JDK คุณต้องการที่จะยอมรับหรือไม่? คุณยังยอมรับไลบรารีผู้อ้างอิงทั้งหมดของคุณหรือไม่

ควรพึ่งพาการอัพเกรดอย่างต่อเนื่องเมื่อมีการออกเวอร์ชั่นใหม่ เพื่อรับความปลอดภัยและแก้ไขข้อผิดพลาดอื่น ๆ และเพราะหากคุณไปถึงด้านหลังอาจเป็นงานที่ต้องใช้เวลามากในการรับข้อมูลใหม่อีกครั้ง

ถ้า wrapper gradle เพิ่มขึ้นสำหรับการเปิดตัวใหม่ทุกครั้งและมีความมุ่งมั่น, repo จะเติบโตขนาดใหญ่มาก ปัญหาชัดเจนเมื่อทำงานกับ VCS แบบกระจายโดยที่โคลนจะดาวน์โหลดทุกรุ่นทุกอย่าง

และโดยไม่รู้ตัวว่ามันทำงานอย่างไร

สร้างบิลด์สคริปต์ที่ดาวน์โหลด wrapper และใช้มันเพื่อบิลด์ ทุกคนไม่จำเป็นต้องรู้ว่าสคริปต์ทำงานอย่างไรพวกเขาจำเป็นต้องยอมรับว่าโครงการนั้นสร้างขึ้นโดยดำเนินการ

, จะดาวน์โหลดจากที่ไหน, เวอร์ชั่นไหน

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

และจากนั้น

gradle wrapper

เพื่อดาวน์โหลดรุ่นที่ถูกต้อง

เพื่อโคลนโครงการจาก VCS เพื่อเรียกใช้งานสคริปต์ gradlew ที่มีอยู่และเพื่อสร้างโครงการโดยไม่มีขั้นตอนเพิ่มเติมใด ๆ

แก้ไขได้ตามขั้นตอนข้างต้น การดาวน์โหลด wrapper gradle ไม่แตกต่างจากการดาวน์โหลดการอ้างอิงอื่น ๆ สคริปต์อาจเป็นสมาร์ท enaugh เพื่อตรวจสอบ wrapper gradle ปัจจุบันใด ๆ และดาวน์โหลดได้เฉพาะถ้ามีรุ่นใหม่

หากผู้พัฒนาไม่เคยใช้ Gradle มาก่อนและอาจไม่ทราบว่าโครงการสร้างด้วย Gradle จากนั้นจะเห็นได้ชัดเจนยิ่งขึ้นในการเรียกใช้ "build.sh" เปรียบเทียบกับการเรียกใช้ "gradlew build"

หากสิ่งที่คุณมีคือหมายเลขรุ่น gradle ในไฟล์ build.gradle คุณจะต้องมี README เพื่ออธิบายให้ทุกคนเห็นว่าต้องดาวน์โหลดรุ่น gradle จาก X URL จาก URL Y

ไม่คุณไม่ต้องการ README คุณสามารถมีหนึ่ง แต่เราเป็นนักพัฒนาและเราควรอัตโนมัติให้มากที่สุด การสร้างสคริปต์จะดีกว่า

และคุณจะต้องทำทุกครั้งที่มีการเพิ่มรุ่น

หากนักพัฒนายอมรับว่ากระบวนการที่ถูกต้องคือ:

1. โคลน repo
2. รันสคริปต์บิลด์

จากนั้นมีการอัพเกรดเป็น wrapper gradle ล่าสุดจะไม่มีปัญหา หากเวอร์ชันนั้นเพิ่มขึ้นตั้งแต่การรันครั้งล่าสุดสคริปต์สามารถดาวน์โหลดเวอร์ชันใหม่ได้

ฉันอยากจะแนะนำวิธีการง่ายๆ

ใน README ของโครงการของคุณเอกสารที่จำเป็นต้องมีขั้นตอนการติดตั้ง ได้แก่ :

gradle wrapper --gradle-version 3.3

ใช้งานได้กับ Gradle 2.4 หรือสูงกว่า สิ่งนี้จะสร้าง wrapper โดยไม่ต้องเพิ่มงานเฉพาะลงใน "build.gradle"

ด้วยตัวเลือกนี้ให้ละเว้น (อย่าเช็คอิน) ไฟล์ / โฟลเดอร์เหล่านี้สำหรับการควบคุมเวอร์ชัน:

• ./gradle
• gradlew
• gradlew.bat

ประโยชน์หลักคือคุณไม่จำเป็นต้องเช็คอินไฟล์ที่ดาวน์โหลดไปยังตัวควบคุมแหล่งที่มา มีค่าใช้จ่ายขั้นตอนพิเศษหนึ่งในการติดตั้ง ฉันคิดว่ามันคุ้มค่า

"โครงการ" คืออะไร?

อาจมีข้อกำหนดทางเทคนิคของสำนวนนี้ที่ไม่รวมสคริปต์สร้าง แต่ถ้าเรายอมรับคำจำกัดความนี้เราต้องบอกว่า "โครงการ" ของคุณไม่ใช่ทุกสิ่งที่คุณต้องการในเวอร์ชัน!

แต่ถ้าเราพูดว่า "โครงการของคุณ" คือทุกอย่างที่คุณได้ทำ จากนั้นเราสามารถพูดได้ว่าคุณจะต้องรวมมันและมันเท่านั้นใน VCS

นี่เป็นทฤษฎีและอาจไม่สามารถใช้ได้ในกรณีที่การพัฒนาของเราทำงาน ดังนั้นเราจึงเปลี่ยนเป็น " โครงการของคุณคือทุกไฟล์ (หรือโฟลเดอร์) คุณต้องแก้ไขโดยตรง "

^{"โดยตรง" หมายถึง "ไม่ทางอ้อม" และ "ทางอ้อม" หมายถึงการแก้ไขไฟล์อื่นแล้วผลกระทบจะปรากฏในไฟล์นี้}

ดังนั้นเราจึงไปถึงที่ OP กล่าว (และได้กล่าวไว้ที่นี่ ):

ฉันคิดว่าไฟล์ที่สร้างขึ้นไม่ควรอยู่ใน VCS

ใช่. เพราะคุณไม่ได้สร้างพวกเขา ดังนั้นจึงไม่ได้เป็นส่วนหนึ่งของ "โครงการของคุณ" ตามคำจำกัดความที่สอง

ผลลัพธ์เกี่ยวกับไฟล์เหล่านี้คืออะไร:

• build.gradle : ใช่ เราจำเป็นต้องแก้ไข งานของเราควรเป็นเวอร์ชั่น

  หมายเหตุ: ไม่มีความแตกต่างเมื่อคุณแก้ไข ไม่ว่าจะเป็นในสภาพแวดล้อมแก้ไขข้อความของคุณหรือในสภาพแวดล้อม GUI โครงสร้างโครงการ อย่างไรก็ตามคุณทำมันโดยตรง !

• gradle-wrapper.properties : ใช่ อย่างน้อยเราต้องระบุเวอร์ชันของ Gradle ในไฟล์นี้

• gradle-wrapper.jarและ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]ในการกระจายท้องถิ่น ไม่จำเป็นว่าการกระจายในท้องที่จะเหมือนกันกับที่กำหนดไว้ใน repo หลังจากสร้างไฟล์ wrapperแล้วgradlew[.bat]สามารถดาวน์โหลด Gradle distribution ที่กำหนดโดยอัตโนมัติ (หากไม่มีอยู่ในเครื่อง) จากนั้นเขา / เธออาจต้องสร้างไฟล์แรปเปอร์ใหม่โดยใช้ไฟล์gradleปฏิบัติการใหม่(ในการแจกแจงแบบดาวน์โหลด) โดยใช้คำแนะนำด้านบน

หมายเหตุ: ในคำแนะนำข้างต้นผู้ใช้ควรมีการกระจาย Gradle อย่างน้อยหนึ่งรายการในเครื่อง (เช่น~/.gradle/wrapper/dists/gradle-4.10-bin/bg6py687nqv2mbe6e1hdtk57h/gradle-4.10) ครอบคลุมเกือบทุกกรณีจริง แต่จะเกิดอะไรขึ้นหากผู้ใช้ยังไม่ได้ทำการแจกจ่ายใด ๆ ?

เขา / เธอสามารถดาวน์โหลดด้วยตนเองโดยใช้ URL ใน.propertiesไฟล์ แต่ถ้าเขา / เธอไม่พบมันในเส้นทางที่เสื้อคลุมคาดว่าเสื้อคลุมจะดาวน์โหลดอีกครั้ง! เส้นทางที่คาดหวังนั้นสามารถคาดเดาได้อย่างสมบูรณ์ แต่อยู่นอกตัวแบบ (ดูที่นี่สำหรับส่วนที่ซับซ้อนที่สุด)

นอกจากนี้ยังมีวิธีที่ง่ายขึ้น (แต่สกปรก) ตัวอย่างเช่นเขา / เธอสามารถคัดลอกไฟล์แรปเปอร์ (ยกเว้น.propertiesไฟล์) จากที่เก็บโลคัล / รีโมตอื่นไปยังที่เก็บของตน / เธอแล้วรันgradlewบนที่เก็บของเขา / เธอ มันจะดาวน์โหลดการกระจายที่เหมาะสมโดยอัตโนมัติ

ตามเอกสารของ Gradleการเพิ่มgradle-wrapper.jarไปยัง VCS นั้นเป็นสิ่งที่คาดว่าจะทำให้ Gradle Wrapper พร้อมใช้งานสำหรับนักพัฒนาเป็นส่วนหนึ่งของแนวทาง Gradle:

ในการทำให้ไฟล์ Wrapper พร้อมใช้งานสำหรับนักพัฒนาคนอื่น ๆ และสภาพแวดล้อมในการทำงานคุณจะต้องตรวจสอบไฟล์เหล่านั้นในการควบคุมเวอร์ชัน ไฟล์ Wrapper ทั้งหมดรวมถึงไฟล์ JAR มีขนาดเล็กมาก คาดว่าจะเพิ่มไฟล์ JAR เข้ากับการควบคุมเวอร์ชัน บางองค์กรไม่อนุญาตให้โครงการส่งไฟล์ไบนารีไปยังการควบคุมเวอร์ชัน ในขณะนี้ยังไม่มีตัวเลือกอื่นให้เลือก

คำถามเก่า ๆ คำตอบใหม่ หากคุณไม่ได้อัพเกรด gradle บ่อยครั้ง (ส่วนมากของเราไม่ได้) จะดีกว่าที่จะผูกมัดมันกับ VCS และเหตุผลหลักสำหรับฉันคือการเพิ่มความเร็วในการสร้างบนเซิร์ฟเวอร์ CI ทุกวันนี้โครงการส่วนใหญ่กำลังสร้างและติดตั้งโดยเซิร์ฟเวอร์ CI, อินสแตนซ์ของเซิร์ฟเวอร์ที่แตกต่างกันทุกครั้ง

หากคุณไม่ยอมรับเซิร์ฟเวอร์ CI จะดาวน์โหลด jar สำหรับทุกบิลด์และมันจะเพิ่มเวลาสร้างอย่างมาก มีวิธีอื่นในการจัดการปัญหานี้ แต่ฉันพบวิธีที่ง่ายที่สุดในการรักษา