ทำไม Maven ถึงมีตัวแทนที่ไม่ดีเช่นนี้? [ปิด]

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

เอกสาร Maven มีน้อยกว่าที่เพียงพอ แต่โดยทั่วไปเมื่อฉันต้องการทำบางสิ่งให้สำเร็จฉันคิดออกเพียงครั้งเดียวแล้วมันก็ใช้งานได้ (เช่นเมื่อฉันใช้การเซ็นชื่อในขวดโหล) ฉันไม่คิดว่า Maven จะยอดเยี่ยม แต่มันช่วยแก้ปัญหาบางอย่างที่ไม่มีมันจะเป็นความเจ็บปวดอย่างแท้จริง

เหตุใด Maven จึงมีตัวแทนที่ไม่ดีและปัญหาอะไรกับ Maven ที่ฉันคาดหวังได้ในอนาคต อาจมีทางเลือกอื่นที่ดีกว่าที่ฉันไม่รู้? (ตัวอย่างเช่นฉันไม่เคยดูรายละเอียดของ Ivy)

หมายเหตุ: นี่ไม่ใช่ความพยายามที่จะทำให้เกิดข้อโต้แย้ง เป็นความพยายามที่จะล้าง FUD

ฉันมองเข้าไปใน maven เมื่อหกเดือนที่แล้ว เรากำลังเริ่มโครงการใหม่และไม่มีมรดกรองรับ ที่กล่าวว่า:

• Maven คือทั้งหมดหรือไม่มีเลย หรืออย่างน้อยที่สุดเท่าที่ฉันสามารถบอกได้จากเอกสาร คุณไม่สามารถใช้ maven แทนการดรอปอินสำหรับมดได้อย่างง่ายดายและค่อยๆใช้คุณสมบัติขั้นสูงเพิ่มเติม
• ตามเอกสารระบุว่า Maven คือความสุขที่ยิ่งใหญ่ที่ทำให้ความฝันอันยิ่งใหญ่ของคุณเป็นจริง คุณต้องทำสมาธิในคู่มือเป็นเวลา 10 ปีก่อนที่คุณจะได้รับการรู้แจ้ง
• Maven ทำให้กระบวนการสร้างของคุณขึ้นอยู่กับการเชื่อมต่อเครือข่ายของคุณ
• Maven มีข้อความแสดงข้อผิดพลาดที่ไร้ประโยชน์ เปรียบเทียบ "Target x ไม่มีอยู่ในโปรเจ็กต์ y" ของ ant กับ "งานที่ไม่ถูกต้อง" ทำงาน "ของ mvn: คุณต้องระบุเฟสวงจรชีวิตที่ถูกต้องหรือเป้าหมายในรูปแบบปลั๊กอิน: goal หรือ pluginGroupId: pluginArtifactId: pluginVersion: goal" Helpfully, แนะนำให้เรียกใช้ mvn ด้วย -e เพื่อดูข้อมูลเพิ่มเติมซึ่งหมายความว่าจะพิมพ์ข้อความเดียวกันจากนั้นสแต็กแทร็กสำหรับ BuildFailureException

ส่วนใหญ่ของความไม่ชอบ maven ของฉันสามารถอธิบายได้โดยข้อความที่ตัดตอนมาจาก Better Builds with Maven:

เมื่อมีคนอยากรู้ว่า Maven คืออะไรพวกเขามักจะถามว่า“ Maven คืออะไร” และพวกเขาคาดหวังคำตอบสั้น ๆ ที่ฟังดูน่าฟัง “ มันเป็นเครื่องมือสร้างหรือกรอบการเขียนสคริปต์” Maven เป็นคำที่น่าเบื่อและไม่น่าสนใจมากกว่าสามคำ เป็นการผสมผสานระหว่างความคิดมาตรฐานและซอฟต์แวร์และเป็นไปไม่ได้ที่จะกลั่นคำจำกัดความของ Maven ให้เป็นเพียงการย่อยสลายเสียง ความคิดปฏิวัติมักยากที่จะถ่ายทอดด้วยคำพูด

ข้อเสนอแนะของฉัน: หากคุณไม่สามารถถ่ายทอดแนวคิดด้วยคำพูดได้คุณไม่ควรพยายามเขียนหนังสือเกี่ยวกับเรื่องนี้เพราะฉันจะไม่ดูดซับความคิดทางกระแสจิต

• มันกำหนดโครงสร้างที่เข้มงวดกับคุณตั้งแต่เริ่มต้น
• เป็นแบบ XML ดังนั้นจึงยากที่จะอ่านเช่นเดียวกับ ANT
• การรายงานข้อผิดพลาดไม่ชัดเจนและทำให้คุณติดค้างเมื่อมีสิ่งผิดปกติเกิดขึ้น
• เอกสารประกอบไม่ดี
• มันทำให้เรื่องยากเป็นเรื่องง่ายและเรื่องง่ายๆก็ยาก
• ใช้เวลามากเกินไปในการรักษาสภาพแวดล้อมการสร้าง Maven ซึ่งเอาชนะจุดที่มีระบบการสร้างแบบร้องเพลงทั้งหมด
• ใช้เวลานานในการพิจารณาว่าคุณพบข้อผิดพลาดใน maven และไม่ได้กำหนดค่าบางอย่างผิดพลาด และข้อบกพร่องก็มีอยู่และในสถานที่ที่น่าแปลกใจ
• มันสัญญามาก แต่ทรยศคุณเหมือนคนรักที่สวยงามและเย้ายวน แต่อารมณ์เย็นชาและชักใย

ฉันเคยร้องไห้และคร่ำครวญเกี่ยวกับ mavenในอดีต แต่ตอนนี้ฉันจะไม่อยู่โดยไม่มีมัน ฉันรู้สึกว่าประโยชน์ที่ได้รับนั้นมีมากกว่าปัญหาใด ๆ หัวหน้า:

• โครงสร้างโครงการที่ได้มาตรฐาน
  • ให้นักพัฒนารายใหม่เข้าร่วมโครงการ:
    • เมื่อคุณบอกว่าเป็นโครงการ Maven นักพัฒนาจะรู้เค้าโครงโครงการและวิธีการสร้างและบรรจุโครงการ
    • เมื่อคุณบอกว่ามันเป็นโครงการ Ant ผู้พัฒนาจะต้องรอให้คุณอธิบายเพิ่มเติมหรือจะต้องผ่าน build.xml เพื่อหาสิ่งต่างๆ
  • แน่นอนว่ามันเป็นไปได้เสมอที่จะกำหนดมาตรฐานทั่วทั้ง บริษัท ด้วย Ant แต่ฉันคิดว่าบ่อยกว่านั้นคุณจะต้องประดิษฐ์วงล้อสุภาษิตขึ้นมาใหม่
• การจัดการการพึ่งพา
  • ไม่ใช่แค่กับไลบรารีภายนอกเท่านั้น แต่ยังรวมถึงไลบรารี / โมดูลภายในด้วย ให้แน่ใจว่าจะใช้พร็อกซีเซิร์ฟเวอร์ที่เก็บ Maven เช่นNexusหรือArtifactory
  • มันเป็นไปได้ที่จะทำบางนี้กับไอวี่ ในความเป็นจริงถ้าสิ่งที่คุณต้องการคือการจัดการการพึ่งพาคุณอาจจะดีกว่าถ้าใช้ Ivy
• โดยเฉพาะภายในโครงการ ฉันพบว่ามันมีประโยชน์มากที่จะแยกโครงการย่อยเล็ก ๆ ออกไปและ maven ก็จัดการเรื่องนี้ได้ดี มดมันยากกว่าเยอะ
• การจัดการสิ่งประดิษฐ์ที่ได้มาตรฐาน (โดยเฉพาะอย่างยิ่งร่วมกับnexusหรือartifactory )
• ปลั๊กอินที่วางจำหน่ายนั้นยอดเยี่ยมมาก
• การรวม Eclipse & NetBeans นั้นค่อนข้างดี
• การผสานรวมกับฮัดสันนั้นยอดเยี่ยมมาก โดยเฉพาะกราฟแนวโน้มของสิ่งต่างๆเช่น findbugs
• มันเป็นจุดเล็ก ๆ น้อย ๆ แต่ความจริงที่ว่า maven ฝังรายละเอียดเช่นหมายเลขเวอร์ชันไว้ใน jar หรือ war (ไม่ใช่แค่ในชื่อไฟล์) โดยค่าเริ่มต้นนั้นมีประโยชน์อย่างมาก

ข้อเสียสำหรับฉันส่วนใหญ่คือ:

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

ฉันเชื่อจริงๆว่ามันคุ้มค่าที่จะใช้เวลาทำความรู้จักกับ maven สักหน่อย

ประสบการณ์จริงของฉันจากโครงการขนาดใหญ่สองโครงการคือเราใช้เวลา 1,000 - 1,500 ชั่วโมงสำหรับแต่ละโครงการในปัญหาที่เกี่ยวข้องกับ maven โดยไม่รวมความพยายาม 500 ชั่วโมงในการย้ายจาก maven 1 ไป maven 2

ตั้งแต่นั้นมาฉันต้องบอกว่าฉันเกลียด maven มาก ฉันรู้สึกหงุดหงิดเมื่อคิดถึงมัน

การรวม Eclipse นั้นแย่มาก (เรามีปัญหาไม่รู้จบในการสร้างโค้ดตัวอย่างเช่นที่คราสซิงค์กับโค้ดที่สร้างขึ้นและจำเป็นต้องสร้างใหม่ทั้งหมดค่อนข้างบ่อยตำหนิมีทั้ง maven และ eclipse แต่ eclipse มีประโยชน์มากกว่า maven และพูดว่า emacs ดังนั้น คราสยังคงอยู่และมาเวนต้องไป)

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

โครงสร้างโครงการ Mavens ไม่เหมาะสำหรับการพัฒนาด้วย Eclipse และเวลาสร้างใน eclipse จะเพิ่มขึ้น

ผลกระทบของการสร้างรหัสและปัญหาการซิงค์เราต้องสร้างใหม่จาก scrach ค่อนข้างบ่อยลดรหัส / คอมไพล์ / รอบการทดสอบของคุณเป็นวงจรคอมไพล์ / websurf / sleep / die / code ที่ไม่มีที่สิ้นสุดส่งคุณกลับไปที่ 90s และ เวลาคอมไพล์ 40 นาที

ข้อแก้ตัวเดียวสำหรับ maven คือการแก้ปัญหาการพึ่งพา แต่ฉันอยากจะทำแบบนั้นนาน ๆ ครั้งไม่ใช่ในทุกงานสร้าง

สรุปได้ว่า maven อยู่ไกลจาก KISS มากที่สุดเท่าที่จะทำได้ และผู้สนับสนุนมักจะเป็นคนประเภทที่เฉลิมฉลองพิเศษในวันเกิดเมื่ออายุเป็นเลขหลัก อย่าลังเลที่จะลงคะแนนให้ฉัน :-)

Maven เยี่ยมมาก เหตุผลที่ทำให้ชื่อเสียงของมันเกี่ยวข้องกับช่วงการเรียนรู้ที่สูงชันในความคิดของฉัน (ซึ่งในที่สุดฉันก็ใกล้จะจบแล้ว)

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

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

ข้อดี:

• การจัดการการพึ่งพา เป็นเวลาหลายปีแล้วที่เพื่อนร่วมงานของฉันและฉันไม่ได้ดาวน์โหลดและจัดการการอ้างอิงด้วยตนเอง ประหยัดเวลาได้มาก
• IDE- ความเป็นอิสระ ปรากฎว่า IDE หลัก ๆ ทั้งหมด Eclipse IDEA และ NetBeans มีการสนับสนุนโครงการ Maven อย่างเหมาะสมอย่างไรดังนั้นนักพัฒนาของเราจึงไม่ถูกล็อคไว้ใน IDE เฉพาะ
• บรรทัดคำสั่ง. ด้วย Maven การรองรับ IDE พร้อมกันและการกำหนดค่าบรรทัดคำสั่งนั้นตรงไปตรงมาซึ่งเหมาะสำหรับการรวมอย่างต่อเนื่อง

จุดด้อย:

• ต้องลงทุนในการเรียนรู้ Maven ดีต้องทำ ข่าวดีไม่ใช่ทุกคนในทีมต้องเรียนรู้
• เอกสารประกอบ. เคยเป็นปัญหาตอนนี้ต้องขอบคุณ Sonatype และหนังสือของพวกเขา ( http://www.sonatype.com/products/maven/documentation/book-defguide ) สถานการณ์ดีขึ้นมาก
• ความแข็ง บางครั้งการทำสิ่งต่างๆในแบบที่คุณต้องการก็เป็นเรื่องท้าทายและน่าผิดหวัง คำแนะนำของฉันจะไม่ต่อสู้และทำให้ Maven ทำสิ่งที่ดีที่สุดสร้างตรงไปตรงมาหรือเมื่อมีโมโจที่มั่นคงพร้อมใช้งาน ในกรณีอื่นเราออกจากงานและทำสิ่งต่างๆด้วย Ant task ( http://maven.apache.org/plugins/maven-antrun-plugin/ ) โปรแกรม orexternal สิ่งที่ฉันชอบคือ Groovy plugun ( http://groovy.codehaus.org/GMaven )

การแข่งขัน:

• Ant: ไม่มีการจัดการการพึ่งพา ระยะเวลา
• Ivy: ยังเป็นผู้ใหญ่น้อยกว่า Maven (ไม่ใช่ว่ารุ่นหลังไม่มีนิสัยใจคอด้วย) เกือบจะเป็นชุดคุณลักษณะเดียวกันดังนั้นจึงไม่มีเหตุผลที่น่าสนใจในการย้าย ฉันพยายามลองหลายครั้ง ไม่ประสบความสำเร็จทั้งหมด

บรรทัดล่าง: โครงการทั้งหมดของเราทำกับ Maven มาหลายปีแล้ว

ฉันคิดว่ามันมีชื่อเสียงที่ไม่ดีกับผู้ที่มีโครงการที่เรียบง่ายและซับซ้อนที่สุด

หากคุณกำลังสร้าง WAR เดียวจากโค้ดเบสเดียวระบบจะบังคับให้คุณย้ายโครงสร้างโปรเจ็กต์ไปรอบ ๆ และแสดงรายการสองจากสามขวดลงในไฟล์ POM ด้วยตนเอง

หากคุณกำลังสร้าง EAR หนึ่งชุดจากชุดของต้นแบบไฟล์ EAR เก้าไฟล์ที่มีการรวมกันของไฟล์ WAR ห้าไฟล์ EJB สามไฟล์และเครื่องมืออื่น ๆ อีก 17 ไฟล์การอ้างอิงและการกำหนดค่าที่ต้องปรับแต่งไฟล์ MANIFEST.MF และ XML ในทรัพยากรที่มีอยู่ระหว่างการสร้างขั้นสุดท้าย Maven มีแนวโน้มที่จะ จำกัด เกินไป โครงการดังกล่าวกลายเป็นความยุ่งเหยิงของโปรไฟล์ที่ซ้อนกันซับซ้อนไฟล์คุณสมบัติและการใช้เป้าหมายการสร้าง Maven และการกำหนดลักษณนามในทางที่ผิด

ดังนั้นหากคุณอยู่ใน 10% ล่างสุดของเส้นโค้งความซับซ้อนแสดงว่ามันโอเวอร์คิล ที่ด้านบน 10% ของเส้นโค้งนั้นคุณอยู่ในช่องแคบแจ็คเก็ต

การเติบโตของ Maven เป็นเพราะทำงานได้ดีในช่วงกลาง 80%

ประสบการณ์ของฉันสะท้อนถึงความไม่พอใจของหลาย ๆ โพสต์ที่นี่ ปัญหาของ Maven คือมันห่อหุ้มและซ่อนรายละเอียดของการจัดการบิลด์ในการแสวงหาความดีอัตโนมัติขั้นสูงสุด สิ่งนี้ทำให้คุณเกือบทำอะไรไม่ถูกถ้ามันพัง

ประสบการณ์ของฉันคือปัญหาใด ๆ กับ maven ลดลงอย่างรวดเร็วในการล่านกปากซ่อมหลายชั่วโมงผ่านเว็บของไฟล์ xml ที่ซ้อนกันในประสบการณ์ที่คล้ายกับรูทคลอง

ฉันยังทำงานในร้านค้าที่ต้องพึ่งพา Maven เป็นอย่างมากคนที่ชอบมัน (ที่ชอบมันในแง่มุม "กดปุ่มทำทุกอย่างให้เสร็จ") ไม่เข้าใจ งานสร้าง maven มีเป้าหมายอัตโนมัติเป็นล้านเป้าหมายซึ่งฉันแน่ใจว่าจะมีประโยชน์ถ้าฉันรู้สึกว่าต้องใช้เวลาหลายชั่วโมงในการอ่านสิ่งที่พวกเขาทำ ดีกว่า 2 เป้าหมายที่ทำงานที่คุณเข้าใจอย่างถ่องแท้

ข้อแม้: ทำงานครั้งล่าสุดกับ Maven เมื่อ 2 ปีก่อนตอนนี้อาจจะดีขึ้น

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

จากประสบการณ์ของฉัน Maven เหมาะสำหรับ:

• การจัดการการพึ่งพาภายนอก
• การจัดการแบบรวมศูนย์ของการสร้าง (การสืบทอด pom)
• ปลั๊กอินมากมายสำหรับสิ่งต่างๆมากมาย
• การผสานรวมที่ดีมากกับเครื่องมือการรวมอย่างต่อเนื่อง
• ความสามารถในการรายงานที่ดีมาก (FindBugs, PMD, Checkstyle, Javadoc, ... )

และมีปัญหาบางอย่างกับ:

• วิธีการทั้งหมดหรือไม่มีอะไรเลย (ยากที่จะโยกย้ายอย่างช้าๆไปยัง Maven)
• การพึ่งพาเชิงซ้อนการพึ่งพาระหว่างโมดูล
• การพึ่งพาวงจร (ฉันรู้ว่าการออกแบบไม่ดี แต่เราไม่สามารถแก้ไข 5 ปีของการพัฒนา ... )
• การเชื่อมโยงกัน (ช่วงของเวอร์ชันไม่ทำงานเหมือนกันทุกที่)
• จุดบกพร่อง (อีกครั้งกับช่วงเวอร์ชัน)
• การสร้างที่ทำซ้ำได้ (เว้นแต่คุณจะแก้ไขหมายเลขเวอร์ชันของปลั๊กอินทั้งหมดคุณไม่สามารถมั่นใจได้ว่าคุณจะได้รับบิลด์เดียวกันใน 6 เดือน)
• ไม่มีเอกสารประกอบ (เอกสารค่อนข้างดีสำหรับพื้นฐาน แต่ไม่มีตัวอย่างวิธีจัดการโครงการขนาดใหญ่มากนัก)

เพื่อให้บริบทบางอย่างมีนักพัฒนาประมาณ 30 คนที่ทำงานในโครงการนี้และโครงการนี้มีมานานกว่า 5 ปีแล้วดังนั้น: มรดกจำนวนมากมีกระบวนการมากมายที่มีอยู่แล้วเครื่องมือที่เป็นกรรมสิทธิ์แบบกำหนดเองจำนวนมากมีอยู่แล้ว เราตัดสินใจลองย้ายไปที่ Maven เนื่องจากค่าใช้จ่ายในการบำรุงรักษาเครื่องมือที่เป็นกรรมสิทธิ์ของเรานั้นสูงเกินไป

ฉันต้องการโต้แย้งข้อร้องเรียนบางประการในฟอรัมนี้:

Maven คือทั้งหมดหรือไม่มีเลย หรืออย่างน้อยที่สุดเท่าที่ฉันสามารถบอกได้จากเอกสาร คุณไม่สามารถใช้ maven แทนการดรอปอินสำหรับมดได้อย่างง่ายดายและค่อยๆใช้คุณสมบัติขั้นสูงเพิ่มเติม

นี่ไม่เป็นความจริง ชัยชนะครั้งใหญ่ของ Maven คือการใช้มันเพื่อจัดการการพึ่งพาของคุณอย่างมีเหตุผลและถ้าคุณต้องการทำสิ่งนั้นใน maven และทำทุกอย่างในมดคุณก็ทำได้ วิธีการมีดังนี้

<?xml version="1.0" encoding="UTF-8"?>
<project name="foo" basedir="." xmlns:maven="antlib:org.apache.maven.artifact.ant" >
  <maven:dependencies verbose="true" pathId="maven.classpath">
    <maven:pom id="maven.pom" file="pom.xml" />
  </maven:dependencies>
</project>

ตอนนี้คุณมีวัตถุ classpath ชื่อ 'maven.classpath' ซึ่งมีการอ้างอิง maven ทั้งหมดที่กำหนดไว้ในไฟล์ pom สิ่งที่คุณต้องมีคือใส่โถงานมด maven ในไดเรกทอรี lib ของมด

Maven ทำให้กระบวนการสร้างของคุณขึ้นอยู่กับการเชื่อมต่อเครือข่ายของคุณ

การอ้างอิงเริ่มต้นและกระบวนการดึงข้อมูลปลั๊กอินขึ้นอยู่กับการเชื่อมต่อเครือข่ายใช่ แต่สำหรับการสร้างเริ่มต้นเท่านั้น (หรือถ้าคุณเปลี่ยนการอ้างอิงหรือปลั๊กอินที่ใช้) หลังจากนั้นไหทั้งหมดจะถูกแคชไว้ในเครื่อง และหากคุณต้องการบังคับให้ไม่มีการเชื่อมต่อเครือข่ายคุณสามารถบอกให้ maven ใช้โหมดออฟไลน์ได้

มันกำหนดโครงสร้างที่เข้มงวดกับคุณตั้งแต่เริ่มต้น

ยังไม่ชัดเจนว่านี่หมายถึงรูปแบบไฟล์หรือปัญหา "การประชุมเทียบกับการกำหนดค่า" อย่างหลังนี้มีค่าเริ่มต้นที่มองไม่เห็นจำนวนมากเช่นตำแหน่งที่คาดไว้ของไฟล์ซอร์ส java และทรัพยากรหรือความเข้ากันได้ของซอร์ส แต่นี่ไม่ใช่ความเข้มงวด แต่เป็นการวางค่าเริ่มต้นที่สมเหตุสมผลสำหรับคุณดังนั้นคุณจึงไม่จำเป็นต้องกำหนดให้ชัดเจน การตั้งค่าทั้งหมดสามารถลบล้างได้อย่างง่ายดาย (แม้ว่าสำหรับผู้เริ่มต้นจะพบได้ยากในเอกสารวิธีการเปลี่ยนแปลงบางอย่าง)

หากคุณกำลังพูดถึงรูปแบบไฟล์ก็จะกล่าวถึงการตอบสนองในส่วนถัดไป ...

เป็นแบบ XML ดังนั้นจึงยากที่จะอ่านเช่นเดียวกับ ANT

ก่อนอื่นฉันไม่เห็นว่าคุณจะบ่นได้อย่างไรว่าบางแง่มุมของบางสิ่งบางอย่าง 'ไม่ดีไปกว่ามด' เป็นเหตุผลที่มีตัวแทนที่ไม่ดี ประการที่สองในขณะที่มันยังคง XML, รูปแบบของ XML ที่มีมากชัดเจนยิ่งขึ้น นอกจากนี้เนื่องจากมีการกำหนดไว้อย่างนั้นจึงง่ายกว่ามากในการสร้างโปรแกรมแก้ไขไคลเอนต์แบบหนาที่เหมาะสมสำหรับ POM ฉันเคยเห็นหน้าสคริปต์สร้างมดยาว ๆ ที่กระโดดไปทั่วทุกที่ โปรแกรมแก้ไขสคริปต์สร้างมดใด ๆ จะไม่ทำให้สิ่งนั้นถูกปากอีกต่อไปเพียงแค่รายการงานที่เชื่อมต่อกันจำนวนมากซึ่งนำเสนอในลักษณะที่แตกต่างกันเล็กน้อย

ต้องบอกว่ามีข้อร้องเรียนบางประการที่ฉันเคยเห็นที่นี่ว่ามีหรือมีชีวิตอยู่บ้างสิ่งมีชีวิตที่ใหญ่ที่สุด

• เอกสารไม่ดี / ขาดหาย
• สร้างซ้ำได้
• การรวม Eclipse ไม่ดี
• บัก

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

ปัญหาการสร้างที่ทำซ้ำได้แบ่งออกเป็นสองปัญหาช่วงเวอร์ชันและการอัปเดตปลั๊กอิน maven อัตโนมัติ สำหรับปลั๊กอินอัปเดตเว้นแต่คุณจะแน่ใจว่าเมื่อคุณสร้างโครงการใหม่ในอีกหนึ่งปีต่อมาว่าคุณใช้ JDK เดียวกันและ Ant เวอร์ชันเดียวกันแน่นอนนี่เป็นเพียงปัญหาเดียวกันกับชื่ออื่น สำหรับช่วงเวอร์ชันฉันขอแนะนำให้ใช้ปลั๊กอินที่จะสร้าง pom ชั่วคราวพร้อมกับเวอร์ชันที่ถูกล็อกสำหรับการอ้างอิงโดยตรงและการส่งผ่านข้อมูลทั้งหมดและทำให้เป็นส่วนหนึ่งของวงจรการเผยแพร่ maven ด้วยวิธีนี้รุ่นบิวด์ปอมรุ่นของคุณจะเป็นคำอธิบายที่แน่นอนของการอ้างอิงทั้งหมดเสมอ

สมควรได้รับชื่อเสียงที่ได้รับ ไม่ใช่ทุกคนที่ต้องการโครงสร้างที่เข้มงวดซึ่งนักพัฒนาของ Maven คิดว่าเหมาะสมสำหรับทุกโครงการ มันไม่ยืดหยุ่นมาก และอะไรคือ 'Pro' สำหรับคนจำนวนมากการจัดการการพึ่งพาคือ IMHO เป็น 'con' ที่ใหญ่ที่สุด ฉันไม่สบายใจอย่างยิ่งกับการดาวน์โหลด maven จากเครือข่ายและสูญเสียการนอนหลับเนื่องจากความเข้ากันไม่ได้ (ใช่มีโหมดออฟไลน์อยู่ แต่ทำไมฉันถึงมีไฟล์ xml และเช็คซัมทั้งหมดหลายร้อยไฟล์) ฉันตัดสินใจว่าฉันใช้ไลบรารีใดและหลายโครงการมีข้อกังวลอย่างมากเกี่ยวกับการสร้างที่ขึ้นอยู่กับการเชื่อมต่อเครือข่าย

ยิ่งไปกว่านั้นเมื่อสิ่งต่างๆไม่ได้ผลคุณจะหลงทางอย่างแน่นอน เอกสารประกอบห่วยชุมชนก็ไม่รู้เรื่อง

หนึ่งปีต่อมาฉันต้องการอัปเดตสิ่งนี้: ฉันไม่มีความคิดเห็นเกี่ยวกับชุมชน Maven นี้อีกต่อไป ฉันจะไม่เขียนคำตอบนี้หากคำถามถูกถามในวันนี้ ฉันจะเพิ่มความคิดเห็นปัจจุบันเป็นคำตอบแยกต่างหาก

นี่เป็นคำตอบที่เป็นส่วนตัวมาก แต่คำถามเกี่ยวกับความคิดเห็นดังนั้น ...

ฉันชอบ Maven และชอบมากขึ้นเมื่อฉันได้รู้จักมันมากขึ้น อย่างไรก็ตามสิ่งหนึ่งที่ส่งผลกระทบต่อความรู้สึกของฉันเกี่ยวกับเรื่องนี้: ชุมชน maven ส่วนใหญ่มีศูนย์กลางอยู่ที่ Sonatype ("บริษัท maven" ซึ่งเป็นที่ที่ Maven honchos หลายคนกำลังทำงานอยู่) และ Sonatype กำลังผลักดันผลิตภัณฑ์ของ บริษัท อย่างจริงจังในชุมชน

ตัวอย่าง: "การ Maven หนังสือ" การเชื่อมโยง Twitter สตรีมไปยังควรรู้เบื้องต้นเกี่ยวกับการจัดการพื้นที่เก็บข้อมูล

ขออภัย "ช่วงแนะนำ" เป็นข้อมูลครึ่งราคาเสนอขายครึ่งราคาสำหรับ Nexus คำถามป๊อป: มีผู้จัดการ repo อื่น ๆนอกเหนือจาก Nexus และ Nexus Pro หรือไม่ นอกจากนี้สิ่งนี้จะเกี่ยวข้องกับหนังสือ Maven ที่มาจากแหล่งใดบ้าง? โอ้ใช่แล้วบทเกี่ยวกับการจัดการที่เก็บได้ถูกแยกออกเป็นเล่มแยกต่างหาก ... เกี่ยวกับ Nexus ฮะ. หากฉันมีส่วนร่วมในหนังสือ Maven ฉันจะได้รับค่าธรรมเนียมการแนะนำหรือไม่หากทำให้ยอดขาย Nexus เพิ่มขึ้น

ลองนึกภาพว่าคุณกำลังเข้าร่วมในฟอรัมการพัฒนา Java หรือไม่และเห็นได้ชัดว่าพนักงานของ Sun ที่พูดคุยเกี่ยวกับ Java กำลังจะคว้าทุกโอกาสที่เป็นไปได้เพื่อพูดคุยเกี่ยวกับ NetBeans และ "NetBeans Pro" หลังจากนั้นไม่นานมันก็เสียความรู้สึกชุมชนไปบ้าง ฉันไม่เคยมีประสบการณ์แบบนั้นกับแอนท์

จากที่กล่าวมาทั้งหมดฉันคิดว่า Maven เป็นระบบที่น่าสนใจและมีประโยชน์มาก (ฉันไม่ได้เรียกมันว่าเครื่องมือเหมือน Ant คือ Maven กว้างกว่านั้น) สำหรับการกำหนดค่าการพัฒนาซอฟต์แวร์และการจัดการบิลด์ การจัดการการพึ่งพาเป็นพรและคำสาปในบางครั้ง แต่ก็สดชื่น - และไม่ใช่ข้อได้เปรียบเพียงอย่างเดียวที่ Maven เสนอ ฉันอาจจะตอบสนองรุนแรงเกินไปกับชิลลิง Sonatype แต่ในความคิดของฉันก็สร้างความเสียหายให้กับ Maven ฉันไม่รู้ว่าความคิดเห็นนี้แชร์โดยใครหรือเปล่า

ฉันคิดว่า Maven ได้รับการลงโทษที่ไม่ดีเพราะมันกำหนดโครงสร้างในโครงการของคุณในขณะที่เครื่องมืออื่น ๆ เช่น Ant ช่วยให้คุณกำหนดโครงสร้างได้อย่างสมบูรณ์ในแบบที่คุณต้องการ เห็นด้วยว่าเอกสารไม่ดี แต่ฉันคิดว่าหลัก ๆ แล้วการแร็พที่ไม่ดีที่ Maven ได้รับเป็นเพราะผู้คนคุ้นเคยกับ Ant มาก

เวทมนตร์มากเกินไป

เพราะคนที่ไม่พอใจจะบ่นในขณะที่คนที่พอใจไม่ได้บอกว่าพวกเขาพอใจ ประเด็นของฉันคือมีผู้ใช้ maven ที่พอใจมากกว่าไม่พอใจ แต่ในภายหลังก็ส่งเสียงดังมากขึ้น นี่เป็นรูปแบบที่พบเห็นได้ทั่วไปจากชีวิตจริงเช่นกัน (ISP ผู้ให้บริการโทรศัพท์การขนส่ง ฯลฯ ฯลฯ )

ปัญหาที่สำคัญที่สุดประการเดียวสำหรับฉันคือ Maven เมื่อไม่ได้รับการกำหนดค่าอย่างถูกต้องอาจไม่สามารถสร้างงานสร้างที่ทำซ้ำได้เนื่องจาก:

• ที่เก็บระยะไกลที่ไม่น่าเชื่อถือ
• การพึ่งพาปลั๊กอินและไลบรารีที่มีเวอร์ชัน SNAPSHOT หรือไม่มีเวอร์ชัน

ตรงกันข้ามกับโครงสร้างมดซึ่งแม้ว่า IMO ที่ละเอียดและน่าเบื่อจะใช้งานได้เนื่องจากมีการตรวจสอบขวดทั้งหมดในเครื่อง

ส่วนที่ดีคือปัญหาสามารถแก้ไขได้:

• ใช้ที่เก็บ maven ของคุณเองซึ่งกลายเป็นเรื่องง่ายไปแล้วฉันใช้Archivaด้วยผลลัพธ์ที่ดี
• ปรับปรุงการอ้างอิงของคุณอย่างถูกต้องเสมอ Maven ได้เริ่มล็อกเวอร์ชันปลั๊กอินใน super-POM โดยเริ่มต้นด้วย 2.0.8 หรือ 2.0.9 และการอ้างอิงทั้งหมดของคุณควรเป็นเวอร์ชันที่วางจำหน่าย

ความคิดที่ดี - การใช้งานที่ไม่ดี

ฉันย้ายโครงการจาก Ant ไปยัง Maven เมื่อเร็ว ๆ นี้ มันทำงานได้ดีในตอนท้าย แต่ฉันต้องใช้ maven-assembly-plugin และ maven-jar-plugin สองเวอร์ชันที่แตกต่างกันใน pom เดียวกัน (มีสองโปรไฟล์) เนื่องจากสิ่งที่ทำงานในเวอร์ชันหนึ่งเสียในอีกเวอร์ชันหนึ่ง

มันจึงค่อนข้างปวดหัว เอกสารอาจไม่ดีเสมอไป แต่ฉันต้องยอมรับว่าคำตอบของ Google นั้นค่อนข้างง่าย

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

ฉันคิดว่าความขัดแย้งมาจากข้อเท็จจริงที่ว่า maven ยังคงมีวิวัฒนาการและบางครั้งกระบวนการก็เจ็บปวด

ความนับถือ

v.

ฉันชอบมาเวน ฉันใช้มาตั้งแต่ก่อน 1.0 เป็นเครื่องมือที่มีประสิทธิภาพที่ช่วยให้ฉันประหยัดเวลาได้มากและปรับปรุงโครงสร้างพื้นฐานการพัฒนาของฉัน แต่ฉันเข้าใจได้ถึงความไม่พอใจของบางคน ฉันเห็นความไม่พอใจ 3 ประเภท:

1. โดยที่สาเหตุเป็นข้อกังวลที่แท้จริง (เช่น verbose POMs ขาดเอกสารประกอบ)
2. ข้อมูลบางส่วนเป็นข้อมูลที่ผิด (เช่น "คุณต้องมีการเชื่อมต่ออินเทอร์เน็ตเพื่อสร้าง" - ไม่เป็นความจริง - ไม่สามารถหลีกเลี่ยงได้)
3. บางส่วนก็ระบายออกมาที่ maven แต่มีคนอื่นที่น่าตำหนิจริงๆ ("อย่ายิงคนส่งสาร")

สำหรับกรณีแรกปัญหาจริง - แน่นอนว่ามีปัญหา POMs เป็นรายละเอียดเอกสารอาจจะดีกว่า อย่างไรก็ตามมันเป็นไปได้ที่จะได้รับผลลัพธ์ที่ดีด้วย maven ในเวลารวดเร็ว ฉันประจบประแจงทุกครั้งที่ได้รับโครงการที่สร้างขึ้นด้วยมดและพยายามนำเข้าสิ่งนี้ใน IDE ของฉัน การตั้งค่าโครงสร้างไดเร็กทอรีอาจใช้เวลานาน ด้วย maven มันเป็นเพียงกรณีของการเปิดไฟล์ POM ใน IDE

สำหรับกรณีที่สอง Maven มีความซับซ้อนและความเข้าใจผิดเป็นเรื่องธรรมดา ถ้า maven 3 สามารถหาวิธีจัดการกับความซับซ้อนนี้ได้ (หรือแม้กระทั่งการรับรู้ความซับซ้อน) ก็คงจะดี maven ใช้เงินลงทุนจำนวนมาก แต่จากประสบการณ์ของฉันการลงทุนจ่ายให้ตัวเองอย่างรวดเร็ว

สำหรับประเด็นสุดท้ายฉันคิดว่าสิ่งที่จับต้องได้เกี่ยวกับการพึ่งพาสกรรมกริยาของ maven น่าจะเป็นตัวอย่างที่รู้จักกันดีที่สุด

การพึ่งพาสกรรมกริยาเป็นลักษณะของซอฟต์แวร์จริงที่ใช้ซ้ำ Windows DLLs, แพ็คเกจ Debian, แพ็คเกจ java, บันเดิล OSGi, แม้แต่ไฟล์ส่วนหัว C ++ ก็มีการอ้างอิงทั้งหมดและประสบปัญหาการพึ่งพา หากคุณมีการพึ่งพาสองแบบและแต่ละแบบใช้สิ่งเดียวกันที่แตกต่างกันคุณต้องพยายามแก้ไขปัญหานั้น Maven ไม่พยายามแก้ปัญหาการพึ่งพา แต่นำไปสู่ระดับแนวหน้าและจัดหาเครื่องมือเพื่อช่วยในการจัดการปัญหาเช่นโดยการรายงานความขัดแย้งและให้การอ้างอิงที่สอดคล้องกันสำหรับลำดับชั้นของโครงการและในความเป็นจริงให้การควบคุมอย่างสมบูรณ์ การอ้างอิงของโครงการ

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

Maven ไม่ใช่สาเหตุของปัญหาการพึ่งพา แต่ทำให้มองเห็นได้ชัดเจนขึ้น ในการแก้ไขปัญหาการพึ่งพา maven ทำให้การพึ่งพาใด ๆ "ปรับแต่ง" อย่างชัดเจน (การเปลี่ยนแปลง POM ของคุณแทนที่การพึ่งพา) แทนที่จะเป็นนัยเช่นเดียวกับกรณีของ jar ที่จัดการด้วยตนเองในการควบคุมเวอร์ชันโดยที่ไหจะปรากฏขึ้นโดยไม่มีอะไรให้ รองรับสภาพอากาศเป็นที่พึ่งที่ถูกต้องหรือไม่

ผมเชื่อว่า Maven มีตัวแทนที่ไม่ดีเพราะผู้ว่าส่วนใหญ่ไม่ได้สังเกตเห็นการรวมกันของผู้เชี่ยวชาญด้าน + ฮัดสัน + Sonar ถ้ามีพวกเขาจะถามว่า "ฉันจะเริ่มต้นอย่างไร"

สัตว์เลี้ยงบางตัวของฉันกับ Maven:

• คำจำกัดความ XML นั้นเงอะงะและละเอียดมาก พวกเขาไม่เคยได้ยินเกี่ยวกับคุณลักษณะหรือไม่?

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

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

• วิธีแก้ปัญหาการเข้าถึงเครือข่ายทั้งหมดนี้คือการปิดโดยเพิ่ม-oตัวเลือก แต่คุณต้องอย่าลืมปิดหากคุณต้องการอัปเดตการพึ่งพาจริงๆ!

• อีกวิธีหนึ่งคือการติดตั้งเซิร์ฟเวอร์ "source control" ของคุณเองสำหรับการอ้างอิง เซอร์ไพร์ส: โปรเจ็กต์ส่วนใหญ่มีการควบคุมซอร์สอยู่แล้วซึ่งใช้งานได้โดยไม่ต้องตั้งค่าเพิ่มเติม!

• การสร้าง Maven นั้นช้าอย่างไม่น่าเชื่อ การเล่นซอกับการอัปเดตเครือข่ายช่วยลดปัญหานี้ได้ แต่การสร้าง Maven ยังช้า และฟุ่มเฟื่อยอย่างน่ากลัว

• ปลั๊กอิน Maven (M2Eclipse) รวมเข้ากับ Eclipse ได้ไม่ดีที่สุด Eclipse ทำงานร่วมกับซอฟต์แวร์ควบคุมเวอร์ชันและ Ant การรวม Maven เป็นเรื่องที่น่าเกลียดและน่าเกลียดมากเมื่อเปรียบเทียบ ฉันพูดช้าหรือเปล่า

• Maven ยังคงเป็นรถบั๊กกี้ ข้อความแสดงข้อผิดพลาดไม่เป็นประโยชน์ นักพัฒนาจำนวนมากเกินไปที่ประสบปัญหานี้

คำถามที่ดี. ฉันเพิ่งเริ่มโครงการขนาดใหญ่ในที่ทำงานและส่วนหนึ่งของโครงการก่อนหน้านี้คือการนำความเป็นโมดูลาร์มาใช้กับฐานรหัสของเรา

ฉันได้ยินเรื่องแย่ ๆ เกี่ยวกับมาเวน อันที่จริงฉันเคยได้ยินเรื่องนี้มาทั้งหมด ฉันมองไปที่การแนะนำเพื่อแก้ปัญหาฝันร้ายจากการพึ่งพาที่เรากำลังประสบอยู่ ปัญหาที่ฉันพบกับ Maven คือโครงสร้างค่อนข้างแข็งกล่าวคือคุณต้องปฏิบัติตามรูปแบบโครงการเพื่อให้มันทำงานให้คุณได้

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

วันนี้มดถูกใช้บ่อยมากและฉันชอบมันมาก การที่เป็นบัญชีที่ฉันเจอผู้จัดการเล็ก ๆ น้อย ๆ ที่รู้จักกันพึ่งพาเรียกว่าApache ไอวี Ivy รวมเข้ากับ Ant ได้เป็นอย่างดีและง่ายและรวดเร็วในการตั้งค่าการดึงข้อมูล JAR ขั้นพื้นฐานและการทำงาน ข้อดีอีกอย่างของ Ivy ก็คือมันทรงพลัง แต่ค่อนข้างโปร่งใส คุณสามารถถ่ายโอนงานสร้างโดยใช้กลไกเช่น scp หรือ ssh ได้อย่างง่ายดาย การดึงข้อมูลการพึ่งพา 'chain' บนระบบไฟล์หรือที่เก็บระยะไกล (ความเข้ากันได้ของ Maven repo เป็นหนึ่งในคุณสมบัติยอดนิยม)

ทั้งหมดที่กล่าวมาฉันพบว่ามันน่าหงุดหงิดมากที่จะใช้ในตอนท้ายเอกสารมีมากมาย แต่มันเขียนเป็นภาษาอังกฤษที่ไม่ดีซึ่งอาจทำให้หงุดหงิดเมื่อทำการดีบั๊กหรือพยายามหาสิ่งที่ผิดพลาด

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

ในที่สุดฉันคิดว่าทั้งหมดนี้ขึ้นอยู่กับวิธีการทำงานของคุณเป็นรายบุคคล / ทีมและสิ่งที่คุณต้องการเพื่อแก้ไขปัญหาการพึ่งพาของคุณ

คุณอาจพบแหล่งข้อมูลต่อไปนี้ที่เกี่ยวข้องกับ Ivy ที่มีประโยชน์:

• การเปรียบเทียบ Apache Ivy กับ Maven 2
• คำถามที่พบบ่อยเกี่ยวกับ Apache Ivy
• รายการคุณสมบัติ Apache Ivy

ฉันรัก Maven - ช่วยเพิ่มผลผลิตและฉันมีความสุขมากที่ไม่ได้ใช้ Ant อีกต่อไป (ว้าว!)

แต่ถ้าฉันสามารถเปลี่ยนแปลงสิ่งต่างๆได้มันจะเป็น:

1. ทำให้pom.xmlไฟล์ verbose น้อยลง
2. ทำให้ง่ายต่อการรวม. jar ที่ไม่ได้มาจากที่เก็บ

มีหลายเหตุผลที่ว่าทำไมคนไม่ชอบ Maven มี แต่ปล่อยให้หน้ามันพวกเขาเป็นส่วนตัวมาก วันนี้ Maven มีหนังสือที่ดี (และฟรี) เอกสารที่ดีกว่าชุดปลั๊กอินที่ใหญ่กว่าและการสร้างโครงการที่ประสบความสำเร็จอ้างอิงจำนวนมากไม่เหมือนกับ Maven เหมือนเมื่อหนึ่งหรือสองปีที่แล้ว

การใช้ Maven ในโครงการที่เรียบง่ายนั้นง่ายมากโดยที่มีขนาดใหญ่ / ซับซ้อนจำเป็นต้องมีความรู้เพิ่มเติมและความเข้าใจที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับปรัชญาของ Maven - ในระดับ บริษัท อาจมีตำแหน่งสำหรับกูรู Maven เช่นผู้ดูแลระบบเครือข่าย แหล่งที่มาหลักของ Maven เกลียด statments มักจะไม่รู้

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

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

ฉันจะไม่บอกว่ามันมีตัวแทนที่ไม่ดีเท่าที่มีตัวแทนผสมกัน หากโครงการของคุณเป็นไปตามกระบวนทัศน์ "convention over configuration" ที่ Maven สนับสนุนคุณจะสามารถใช้ประโยชน์จากมันได้มาก หากโครงการของคุณไม่เข้ากับมุมมองโลกของ Maven ก็อาจกลายเป็นภาระได้

ด้วยเหตุนี้หากคุณมีอำนาจควบคุมโครงการ Maven อาจเป็นหนทางไป แต่ถ้าคุณทำไม่ได้และเค้าโครงถูกกำหนดโดยคนที่ไม่ใช่แฟนของ Maven อาจเป็นปัญหามากกว่าที่คิด โครงการ Maven ที่มีความสุขที่สุดน่าจะเป็นโครงการที่เริ่มต้นจากโครงการ Maven

สำหรับฉันมีข้อดีหลายประการเช่นเดียวกับข้อเสียในการใช้ maven vs ant สำหรับโครงการในบ้าน อย่างไรก็ตามสำหรับโครงการโอเพ่นซอร์สฉันคิดว่า Maven มีผลอย่างมากในการทำให้หลาย ๆ โครงการสร้างได้ง่ายขึ้นมาก เมื่อไม่นานมานี้ใช้เวลาหลายชั่วโมงในการรวบรวมโปรเจ็กต์ OSS Java (ant based) โดยเฉลี่ยต้องตั้งค่าตัวแปรจำนวนมากดาวน์โหลดโปรเจ็กต์ที่พึ่งพา ฯลฯ

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

หากคุณกำลังจะเดิมพันธุรกิจหรืองานของคุณในโครงการพัฒนาคุณต้องการเป็นผู้ควบคุมฐานรากนั่นคือระบบสร้าง ด้วย Maven คุณไม่สามารถควบคุมได้ เป็นแบบเปิดเผยและทึบแสง นักพัฒนา maven-framework ไม่มีความคิดที่จะสร้างระบบที่โปร่งใสหรือใช้งานง่ายและสิ่งนี้ชัดเจนจากเอาต์พุตบันทึกและเอกสารประกอบ

การจัดการการพึ่งพาเป็นสิ่งที่น่าดึงดูดมากเนื่องจากอาจทำให้คุณรู้สึกเหมือนกันในช่วงเริ่มต้นโครงการ แต่ขอเตือนไว้ก่อนว่ามันมีปัญหาโดยพื้นฐานและจะทำให้คุณปวดหัวในที่สุด เมื่อการพึ่งพาสองอย่างมีการพึ่งพาชั่วคราวที่เข้ากันไม่ได้คุณจะถูกปิดกั้นโดยรังของความซับซ้อนของหนูที่จะทำลายโครงสร้างสำหรับทั้งทีมของคุณและบล็อกการพัฒนาเป็นเวลาหลายวัน กระบวนการสร้างด้วย Maven นั้นไม่สอดคล้องกันอย่างฉาวโฉ่สำหรับนักพัฒนาที่แตกต่างกันในทีมของคุณเนื่องจากสถานะของที่เก็บในเครื่องไม่สอดคล้องกัน ขึ้นอยู่กับเวลาที่นักพัฒนาสร้างสภาพแวดล้อมของพวกเขาหรือโครงการอื่น ๆ ที่พวกเขากำลังดำเนินการอยู่พวกเขาจะได้ผลลัพธ์ที่แตกต่างกัน คุณจะพบว่าคุณกำลังลบที่เก็บในเครื่องของคุณทั้งหมดและมี Maven ดาวน์โหลดไหซ้ำบ่อยกว่าการตั้งค่าครั้งแรกสำหรับสาขา dev ฉันเชื่อว่า OSGI เป็นโครงการริเริ่มที่พยายามแก้ไขปัญหาพื้นฐานนี้ ฉันจะบอกว่าบางทีถ้าบางสิ่งจำเป็นต้องซับซ้อนมากหลักฐานพื้นฐานก็ผิด

ฉันเป็นผู้ใช้ / เหยื่อ maven มานานกว่า 5 ปีแล้วและฉันต้องบอกว่ามันจะช่วยให้คุณประหยัดเวลามากขึ้นในการตรวจสอบการอ้างอิงของคุณในที่เก็บต้นทางของคุณและเขียนงานมดที่ดีและเรียบง่าย ด้วยมดคุณรู้ดีว่าระบบสร้างของคุณกำลังทำอะไรอยู่

ฉันเคยประสบกับมนุษย์ที่สูญเสียมาหลายสัปดาห์ใน บริษัท ต่างๆหลายแห่งเนื่องจากปัญหาของ Maven

ฉันเพิ่งพยายามทำให้โครงการ GWT / Maven / Eclipse เก่ากลับมามีชีวิตอีกครั้งและ 2 สัปดาห์จากเวลาว่างทั้งหมดในภายหลังฉันก็ยังไม่สามารถสร้างได้อย่างสม่ำเสมอ ถึงเวลาลดการสูญเสียและพัฒนาโดยใช้ ant / eclipse ที่ฉันคิด ...

คำตอบสั้น ๆ : ฉันพบว่ามันยากมากที่จะดูแลระบบการสร้าง Maven และฉันต้องการเปลี่ยนไปใช้ Gradle โดยเร็วที่สุด

ฉันทำงานกับ Maven มานานกว่าสี่ปี ฉันจะเรียกตัวเองว่าเป็นผู้เชี่ยวชาญด้านระบบการสร้างเพราะในห้า บริษัท ที่ผ่านมา (อย่างน้อย) ที่ฉันเคยอยู่ฉันได้ทำการปรับปรุงโครงสร้างพื้นฐานการสร้าง / ปรับใช้ครั้งใหญ่

บทเรียนบางส่วนที่ฉันได้เรียนรู้:

• นักพัฒนาส่วนใหญ่มักจะไม่ใช้เวลาคิดมากเกี่ยวกับระบบการสร้าง เป็นผลให้งานสร้างกลายเป็นแฮ็กสปาเก็ตตี้ที่ยุ่งเหยิง แต่พวกเขารู้สึกขอบคุณเมื่อความยุ่งนั้นถูกล้างและหาเหตุผลเข้าข้างตนเอง
• ในการจัดการกับความซับซ้อนฉันค่อนข้างจะมีระบบโปร่งใสที่เปิดเผยความซับซ้อน (เช่น Ant) มากกว่าระบบที่พยายามทำให้สิ่งที่ซับซ้อนเป็นเรื่องง่ายโดยกำหนดข้อ จำกัด ที่เข้มงวดเช่น Maven ลองนึกถึง Linux เทียบกับ Windows
• Maven มีช่องโหว่มากมายในการทำงานซึ่งต้องใช้วิธีแก้ปัญหาแบบไบเซนไทน์ สิ่งนี้นำไปสู่ไฟล์ POM ที่ไม่สามารถเข้าใจได้และไม่สามารถเข้าถึงได้
• Ant มีความยืดหยุ่นสูงและเข้าใจได้ง่าย แต่ไฟล์ Ant ก็มีขนาดใหญ่เช่นกันเพราะมันอยู่ในระดับต่ำ
• สำหรับโครงการสำคัญใด ๆ นักพัฒนาจะต้องสร้างโครงสร้างการสร้าง / ปรับใช้ของตนเองนอกเหนือจากที่เครื่องมือจัดเตรียมไว้ให้ ความเหมาะสมของโครงสร้างกับโครงการมีส่วนเกี่ยวข้องกับความง่ายในการดูแลรักษา เครื่องมือที่ดีที่สุดจะสนับสนุนคุณในการสร้างโครงสร้างและไม่ต่อสู้กับคุณ

ฉันได้ดู Gradle เล็กน้อยและดูเหมือนว่ามันมีศักยภาพที่จะเป็นสิ่งที่ดีที่สุดของทั้งสองโลกทำให้สามารถผสมผสานระหว่างคำอธิบายการสร้างที่เปิดเผยและขั้นตอนได้

มันซับซ้อนกว่าภาษาที่คุณใช้เขียนโครงการ การกำหนดค่าให้ถูกต้องยากกว่าการเขียนโปรแกรมจริง

ฉันพยายามดิ้นรนผ่านทางลบส่วนใหญ่ / ทั้งหมดที่กล่าวถึงที่นี่และการคัดค้านที่คล้ายกันจากเพื่อนร่วมทีมและเห็นด้วยกับพวกเขาทั้งหมด แต่ฉันยึดติดกับมันและจะทำเช่นนั้นต่อไปโดยยึดมั่นในวัตถุประสงค์เดียวที่มีเพียง maven (หรืออาจจะไล่เลี่ย) ให้ได้จริงๆ

หากคุณกำลังเพิ่มประสิทธิภาพสำหรับเพื่อนร่วมงาน ( นักพัฒนาโอเพ่นซอร์ส) ant / make / อะไรก็ตามที่จะทำ หากคุณกำลังส่งมอบฟังก์ชันให้กับผู้ที่ไม่ใช่เพื่อน ( ผู้ใช้ ) จะมีเพียง maven / gradle / etc เท่านั้นที่ทำ

มีเพียง maven เท่านั้นที่ช่วยให้คุณสามารถปล่อยซอร์สโค้ด + poms ขนาดเล็ก (ไม่มี lib / binary dependency jars ที่ฝังไว้ด้วยชื่อที่เป็นความลับและไม่มีข้อมูลอ้างอิง) พร้อมด้วยเค้าโครงโครงการมาตรฐานที่มีเอกสารอย่างดีซึ่งสามารถโหลดโดย IDE ใด ๆ โดยบุคคลที่ไม่ได้ดูดซึม รูปแบบการจัดวางที่แปลกประหลาดของนักพัฒนา และมีขั้นตอนการติดตั้งด้วยปุ่มเดียว (การติดตั้ง mvn) ที่สร้างทุกอย่างในขณะที่ได้รับการอ้างอิงที่ขาดหายไป

ผลลัพธ์ที่ได้คือการใช้ทางลาดที่ง่ายที่ผู้ใช้สามารถปฏิบัติตามเพื่อหาทางเข้าไปในโค้ดซึ่ง poms สามารถชี้ให้พวกเขาดูเอกสารที่เกี่ยวข้องได้

นอกเหนือจากข้อกำหนด (แยกไม่ออก) แล้วฉันไม่ชอบมาเวนเท่าใคร