คำถามติดแท็ก dependency-management

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

68 packages  dependency-management  package-managers 

เรามีสองวิกฤตที่เกี่ยวข้องกับการพึ่งพาที่สำคัญสองฐานรหัสที่แตกต่างกัน (Android และเว็บแอป Node.js) repo Android จำเป็นต้องโยกย้ายจาก Flurry ไปยัง Firebase ซึ่งจำเป็นต้องอัปเดตห้องสมุด Google Play Services สี่เวอร์ชันหลัก มีสิ่งที่คล้ายกันเกิดขึ้นกับแอปโหนดที่โฮสต์โดย Heroku ซึ่งสแตกการผลิต (ซีดาร์) ของเราถูกเลิกใช้และจำเป็นต้องได้รับการอัพเกรดเป็นซีดาร์ -14 ฐานข้อมูล PostgreSQL ของเรายังต้องมีการอัพเดทจาก 9.2 เป็น 9.6 แต่ละแอพพลิเคชั่นของแอพเหล่านี้นั่งค้างได้เกือบสองปีและเมื่อแอพบางตัวเลิกใช้งานและเราถึงช่วงเวลา 'พระอาทิตย์ตก' มันเป็นอาการปวดหัวที่สำคัญในการอัปเดตหรือแทนที่ ฉันใช้เวลากว่า 30 ชั่วโมงในช่วงหนึ่งเดือนที่ผ่านมาหรือสองชั่วโมงค่อย ๆ แก้ไขข้อขัดแย้งและรหัสที่เสียหายทั้งหมด เห็นได้ชัดว่าการปล่อยให้สิ่งต่าง ๆ นั่งเป็นเวลาสองปีนั้นยาวนานเกินไป เทคโนโลยีดำเนินไปอย่างรวดเร็วโดยเฉพาะเมื่อคุณใช้ผู้ให้บริการแพลตฟอร์มอย่าง Heroku สมมติว่าเรามีชุดทดสอบเต็มรูปแบบและกระบวนการ CI เช่น Travis CI ซึ่งใช้การคาดเดามากมายในการอัปเดต เช่นถ้าฟังก์ชั่นถูกลบออกหลังจากการอัพเกรดและคุณใช้มันการทดสอบของคุณจะล้มเหลว ควรอัปเดตการอ้างอิงบ่อยเพียงใดหรือควรอัปเดตการอ้างอิงเมื่อใด เราอัปเดตเพราะเราถูกบังคับ แต่ดูเหมือนว่าวิธีการจองล่วงหน้าบางประเภทจะดีกว่า …

30 dependencies  dependency-management 

สมมติว่าฉันมีโครงการที่ขึ้นอยู่กับห้องสมุด 10 แห่งและภายในโครงการของฉันฉันสามารถใช้ไลบรารี่รุ่นใดก็ได้ ดังนั้นฉันเริ่มต้นด้วยรุ่นล่าสุด จากนั้นแต่ละไลบรารีจะได้รับการอัพเดตเดือนละครั้ง (โดยเฉลี่ย) ตอนนี้การรักษาลำตัวของฉันให้ทันสมัยอยู่เสมอจะต้องอัพเดตการอ้างอิงห้องสมุดทุกสามวัน เห็นได้ชัดว่ามันมากเกินไป ถึงแม้ว่าโดยปกติแล้วรุ่น 1.2.3 จะเป็นแบบดรอปดาวน์แทนรุ่น 1.2.2 แต่คุณก็ยังไม่มีทางรู้ว่าจะทำการทดสอบ การทดสอบหน่วยไม่เพียงพอ ถ้าเป็นโปรแกรมฐานข้อมูล / ไฟล์คุณต้องตรวจสอบให้แน่ใจว่ามันทำงานอย่างถูกต้องกับไฟล์ที่สร้างขึ้นด้วยเวอร์ชันที่เก่ากว่าและอาจกลับกัน ถ้ามันมีบางอย่างเกี่ยวกับ GUI คุณต้องตรวจสอบทุกอย่างด้วยสายตา และอื่น ๆ คุณจัดการกับสิ่งนี้ได้อย่างไร แนวทางที่เป็นไปได้บางประการ: ถ้าไม่ได้ยากจนไม่สามารถแก้ไขได้ อยู่กับไลบรารี่รุ่นปัจจุบันของคุณตราบใดที่คุณไม่สังเกตเห็นอะไรผิดปกติกับไลบรารี่ที่ใช้ในแอปพลิเคชั่นของคุณ การเปลี่ยนแปลงเล็ก ๆ น้อย ๆ ที่เพิ่มขึ้นนั้นเป็นเพียงของเสีย อัปเดตบ่อยครั้งเพื่อให้การเปลี่ยนแปลงเล็ก ๆ เนื่องจากคุณจะต้องอัปเดตทุกวันไม่ว่ากรณีใด ๆ จึงเป็นการดีกว่าที่จะอัปเดตบ่อยครั้งเพื่อให้คุณสังเกตเห็นปัญหาก่อนเวลาเมื่อแก้ไขได้ง่ายแทนที่จะกระโดดข้ามหลายเวอร์ชันและปล่อยให้ปัญหาที่อาจเกิดขึ้นสะสม บางสิ่งบางอย่างในระหว่าง มีจุดหวานหรือไม่?

28 third-party-libraries  dependency-management 

TL: DR: ทำไมจึงต้องใช้Apache ArchivaหรือSonatype Nexusเป็นแหล่งเก็บข้อมูลสิ่งประดิษฐ์แทนการโค่นล้ม? ระบบการสร้างที่ฉันใช้ในปัจจุบันมีจำนวนมากของ blobs ไบนารี (รูปภาพไฟล์เสียงไบนารีที่คอมไพล์แล้ว) ทั้งเป็นอินพุตและเอาต์พุตไปยังบิลด์ของเรา ระบบของเราสำหรับการจัดการสิ่งเหล่านี้เป็นสิ่งที่พิเศษมาก บางอันถูกตรวจสอบในที่เก็บโค่นล้มของเราพร้อมกับรหัสของเราบางอันถูกเก็บไว้ที่อื่นนอกการควบคุมเวอร์ชันทางการ ฉันกำลังดูการรวมสิ่งนี้เข้าด้วยกันดังนั้นเราจึงมีบางสิ่งที่สอดคล้องกับตัวเองและใช้งานง่ายกว่าและแยกสิ่งประดิษฐ์ไบนารีออกจากโค้ด Google บอกฉันว่ามีคลังเก็บวัตถุให้เลือกมากมาย ( Archiva , Nexus , Artifactory , …) แต่จากการอ่านไปรอบ ๆ ฉันไม่เห็นประโยชน์ใด ๆ จากการใช้ Subversion สิ่งนี้จะช่วยดูแลไบนารีของเรา - มันได้ทำไปแล้วสำหรับไบนารีบางตัวของเราเราแค่ต้องการจัดเรียงเลย์เอาต์ใหม่เพื่อแยกพวกมันออกจากโค้ด - และมีข้อได้เปรียบที่โดดเด่นที่เรามีเซิร์ฟเวอร์โค่นล้มและความเชี่ยวชาญ ดังนั้น. อะไรคือข้อดีของการใช้ระบบจัดการสิ่งประดิษฐ์เฉพาะโดยใช้เครื่องมือควบคุมเวอร์ชันทั่วไปเช่นการโค่นล้ม?

19 svn  dependency-management 

ฉันกำลังมองหาคำตอบใน SO หรือที่นี่ แต่ไม่มีผลลัพธ์ใด ๆ นั่นคือเหตุผลที่ฉันจะถามคุณ สมมติว่าฉันมีสองโครงการที่แตกต่างกัน - ตัวอย่างเช่นส่วนของเซิร์ฟเวอร์และส่วนลูกค้าของแอพ ฉันกำลังพัฒนาส่วนของตัวเองในขณะที่เพื่อนของฉันกำลังสร้างส่วนที่สอง แต่ทั้งสองของเราควรจะใช้อินเตอร์เฟซบางอย่างร่วมกันเช่นUserหรือAccountInfoหรือChangableAccount... สิ่งเพื่อให้แน่ใจว่าการทำงานร่วมกัน ตัวอย่างเช่นหากลูกค้าส่งข้อมูลผู้ใช้ไปยังเซิร์ฟเวอร์เซิร์ฟเวอร์ควรทำงานในคลาสเดียวกัน เหมือนกับอินเทอร์เฟซและอื่น ๆ นอกจากนี้หากมีการเปลี่ยนแปลงใด ๆ ในอินเทอร์เฟซทั่วไปโครงการทั้งสองควรปรับรหัสให้เป็นสถานการณ์ใหม่ ทางออกเดียวที่ฉันเห็นในตอนนี้คือการสร้างโครงการพิเศษหนึ่งโครงการซึ่งกำหนดสิ่งทั่วไปทั้งหมดไว้ เราฉันและเพื่อนของฉันควรเพิ่มโครงการนี้เป็นการอ้างอิงไปยังโครงการหลัก (ไคลเอนต์หรือเซิร์ฟเวอร์) โครงการที่ใช้ร่วมกันสามารถจัดการได้โดยระบบควบคุมเวอร์ชันบางระบบดังนั้นเราจึงมีสถานะที่ทันสมัยที่สุดเสมอ คุณจะแนะนำโซลูชันอื่นใดอีก ปัญหาดังกล่าวได้รับการแก้ไขอย่างไรในแอพมืออาชีพ

17 java  dependencies  integration  dependency-management 

ฉันต้องการคำแนะนำเกี่ยวกับองค์กรของชุดโครงการ C ++ ที่เกี่ยวข้อง แต่เป็นอิสระที่เก็บไว้ในที่เก็บ (git) เดียว โครงการใช้ CMake สำหรับตัวอย่างที่ง่ายเรานึกภาพ 2 โครงการ A และ B ขึ้นอยู่กับ B. คนส่วนใหญ่ที่พัฒนา A จะได้รับ B ผ่านระบบบรรจุภัณฑ์ ดังนั้นพวกเขาจะรวบรวมเพียง A. อย่างไรก็ตามเราควรอนุญาตให้นักพัฒนาคอมไพล์ทั้ง A และ B เอง (และติดตั้ง) แยกกันหรือรวมกัน นี่คือข้อเสนอ: └── Repo1 ├── CMakeLists.txt (1) ├── A │ ├── CMakeLists.txt (2) │ ├── include │ │ ├── aaa.h …

12 c++  organization  code-organization  dependency-management  cmake 

ฉันมีโครงสร้างโครงการเช่นนี้: My Project - Other Team's Project -Third Party Dependency My Projectต้องการOther Team's Projectฟังก์ชั่นและทั้งสองMy ProjectและOther Team's Projectจำเป็นต้องมีThird Party Dependencyฟังก์ชั่น เรากำลังใช้ระบบการจัดการการพึ่งพาเพื่อจัดการสิ่งเหล่านี้ จากมุมมองการออกแบบจะดีกว่าที่จะMy Projectพึ่งพาการขนส่งThird Party Dependencyหรือไม่ หรือมันจะดีกว่าสำหรับทั้งสองMy ProjectและOther Team's Projectทั้งสองอย่างชัดเจนประกาศว่าพวกเขาใช้Third Party Dependency? สิ่งอื่น ๆ : Third Party Dependencyทั้งสองโครงการจะต้องมีรุ่นเดียวกัน ไม่รับประกันว่าหากOther Team's Projectได้รับการปรับปรุงที่My Projectจะถูกทดสอบเพื่อให้แน่ใจว่าไม่มีอะไรแตกเพราะได้รับการจัดการโดยทีมที่แตกต่างกัน

11 dependency-management 

ฉันมีโครงการที่ใช้ไลบรารี C / C ++ โอเพ่นซอร์ส 3-4 แบบ ฉันสร้างไลบรารีเหล่านี้สำหรับหลายแพลตฟอร์มและเช็คอินรวมไฟล์และ libs แบบคงที่สำหรับแพลตฟอร์มต่าง ๆ ในโครงการของฉัน อย่างไรก็ตามฉันต่อสู้กับปัญหาสองสามอย่าง โครงการทั้งหมดเหล่านี้เป็นการบริหารการพึ่งพา และฉันกำลังมองหาคำแนะนำวิธีปฏิบัติที่ดีที่สุด 1) ฉันจะรู้ได้อย่างไรว่าฉันใช้อะไรกันแน่ ฉันไม่มีทางที่จะไปรับ lib แบบคงที่ เป็นผลให้ฉันต้องติดตามอย่างใดอย่างหนึ่ง lib แบบคงที่ฉันใช้ (อาจ SHA ของการกระทำที่มันถูกสร้างขึ้น)? นี่เป็นสิ่งสำคัญอย่างยิ่งเมื่อฉันต้องคิดเมื่อต้องอัพเกรด libs เหล่านี้ 2) ฉันจะสร้างงานสร้างใหม่ได้อย่างไร ฉันอาจพยายามสร้างห้องสมุดเฉพาะสำหรับแพลตฟอร์มเฉพาะ ฉันใช้เวลาซักพักนึง ครั้งต่อไปที่ฉันจะต้องสร้างห้องสมุดเดียวกันอาจจะเป็นในครึ่งปี (เมื่อฉันจะต้องอัพเกรดด้วยเหตุผลใดก็ตามอย่างไรก็ตามในเวลานั้นฉันจะไม่จำอะไรและสภาพแวดล้อมที่มันถูกสร้างขึ้น จะหายไปนาน 3) ฉันควรแยกไลบรารี่เหล่านี้ให้มีซอร์สโค้ดหรือไม่ นี่เป็นข้อกังวลที่น้อยกว่า อย่างไรก็ตามมันยังคงเป็นปัญหา เป็นเรื่องดีที่จะตรวจสอบให้แน่ใจว่าบิลด์นั้นสามารถทำซ้ำได้ (และประเภทนั้นต้องการซอร์สโค้ด)

11 c++  c  builds  dependency-management 

พื้นหลัง ฉันมีโครงการที่ขึ้นอยู่กับการใช้งานของอุปกรณ์ฮาร์ดแวร์บางประเภทในขณะที่มันไม่สำคัญว่าใครจะทำอุปกรณ์ฮาร์ดแวร์นั้นตราบเท่าที่มันเป็นสิ่งที่ฉันต้องทำ จากที่กล่าวมาแม้กระทั่งอุปกรณ์สองชิ้นที่ควรทำในสิ่งเดียวกันจะมีความแตกต่างเมื่อไม่ได้ผลิตโดยผู้ผลิตรายเดียวกัน ดังนั้นฉันจึงคิดว่าจะใช้อินเทอร์เฟซเพื่อแยกแอปพลิเคชันออกจากอุปกรณ์/ รุ่นที่เกี่ยวข้องและมีอินเทอร์เฟซที่ครอบคลุมฟังก์ชั่นระดับสูงสุดแทน นี่คือสิ่งที่ฉันคิดว่าสถาปัตยกรรมของฉันจะมีลักษณะ: กำหนดอินเตอร์เฟซใน C # IDeviceโครงการหนึ่ง มีรูปธรรมในห้องสมุดที่กำหนดไว้ในโครงการ C # อื่นที่จะใช้เพื่อเป็นตัวแทนของอุปกรณ์ มีอุปกรณ์ที่เป็นรูปธรรมใช้IDeviceอินเตอร์เฟซ IDeviceอินเตอร์เฟซที่อาจจะมีวิธีการเช่นหรือGetMeasurementSetRange ทำให้แอปพลิเคชันมีความรู้เกี่ยวกับรูปธรรมและส่งผ่านรูปธรรมไปยังรหัสแอปพลิเคชั่นที่ใช้งาน ( ไม่นำไปใช้ ) IDeviceอุปกรณ์ ฉันค่อนข้างแน่ใจว่านี่เป็นวิธีที่ถูกต้องที่จะไปเกี่ยวกับเรื่องนี้เพราะแล้วฉันจะสามารถเปลี่ยนอุปกรณ์ที่ใช้โดยไม่ส่งผลกระทบต่อแอปพลิเคชัน (ซึ่งดูเหมือนว่าจะเกิดขึ้นบางครั้ง) กล่าวอีกนัยหนึ่งมันไม่สำคัญว่าการใช้งานGetMeasurementหรือSetRangeทำงานผ่านคอนกรีตอย่างแท้จริง (อาจแตกต่างกันระหว่างผู้ผลิตอุปกรณ์) ข้อสงสัยเดียวในใจของฉันคือตอนนี้ทั้งแอปพลิเคชันและคลาสที่เป็นรูปธรรมของอุปกรณ์นั้นขึ้นอยู่กับไลบรารีที่มีIDeviceส่วนต่อประสาน แต่นั่นเป็นสิ่งที่ไม่ดี? ฉันไม่เห็นด้วยว่าแอปพลิเคชันไม่จำเป็นต้องรู้เกี่ยวกับอุปกรณ์ได้อย่างไรนอกจากอุปกรณ์และIDeviceอยู่ในเนมสเปซเดียวกัน คำถาม ดูเหมือนว่าวิธีการที่ถูกต้องสำหรับการใช้อินเทอร์เฟซเพื่อแยกการพึ่งพาระหว่างแอปพลิเคชันของฉันและอุปกรณ์ที่ใช้หรือไม่

10 c#  design-patterns  object-oriented  interfaces  dependency-management 

เรามีแอพพลิเคชั่นและบริการบนเว็บมากมาย (ผลิตภัณฑ์สาธารณะบางผลิตภัณฑ์, ภายในและส่วนหนึ่งของ "แบ็กเอนด์" ส่วนตัว) ที่พึ่งพาซึ่งกันและกัน แต่ละองค์ประกอบเหล่านี้มี 4 สภาพแวดล้อม (กลุ่มของเซิร์ฟเวอร์ / โหนดที่ให้บริการตามวัตถุประสงค์เฉพาะ): ที่ไม่ใช่การผลิต DEV- สภาพแวดล้อมการพัฒนาแบบบูรณาการที่ CI สร้างการเปลี่ยนแปลงแบบพุช มีประโยชน์สำหรับวิศวกรในการแก้ปัญหาข้อบกพร่องที่หายากที่ไม่สามารถทำซ้ำได้ QA - แยก QA / สภาพแวดล้อมการทดสอบ DEMO - สภาพแวดล้อมของ UAT ที่เสถียรสำหรับผู้มีส่วนได้เสีย การผลิต LIVE - สภาพแวดล้อมสด / การผลิตของเรา รหัสโปรโมชั่ไป: LOCAL(เครื่องของนักพัฒนา) => DEV=> QA=> =>DEMOLIVE บอกว่าเรามีโปรแกรมที่เรียกว่าmyappที่มีการสนับสนุนจากบริการเว็บ RESTful เรียกว่าmywsที่ตัวเองได้รับการสนับสนุนโดย DB mydbที่เรียกว่า ขณะนี้เรามีสิ่งที่ผมจะเรียกว่า " บงการ " …

10 continuous-integration  release-management  dependency-management  environment 

เมื่อเร็ว ๆ นี้ฉันเริ่มเล่นกับ node.js ทีนี้ทุก ๆ บทช่วยสอนจะบอกว่าคุณควรเริ่มด้วย npm init จากนั้นพูดว่าคุณต้องการเฟรมเวิร์กเซิร์ฟเวอร์มาตรฐานพูดว่าคุณเลือกด่วน: npm install express แต่คุณจะต้องการสิ่งอื่น ๆ อีกมากมายที่คุณคุ้นเคยจากโลกอย่าง ASP.NET ฉันพูดเกี่ยวกับแม่แบบเอ็นจิ้น (หยก) และสไตล์พรีโปรเซสเซอร์ (SASS) แล้วพวกเขาก็บอกคุณว่า "ติดตั้ง gulp / grunt! เพื่อให้คุณสามารถลดขนาดและทำให้อัปเดตและรันเซิร์ฟเวอร์และสิ่งอื่น ๆ อีกมากมายโดยอัตโนมัติ!" และนั่นหมายถึงการติดตั้ง gulp, node-sass และ gulp-sass และ gulp-uglify และอาจจะมีสิ่งดีๆอีกมากมาย (tsd หรือ babel, markdown ฯลฯ ) ... แต่สิ่งเหล่านั้นมีอยู่มากในดิสก์และโปรเจ็กต์ อย่าค้นหาสักครู่และคุณสามารถค้นหาตัวเองด้วยขนาดดิสก์ 100MB + สำหรับโครงการนั้น (ซึ่งยังไม่ได้เริ่มเลย!) …

10 node.js  dependency-management 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ปกติคุณจะเข้าถึงปัญหาการพึ่งพาสกรรมกริยาที่เกิดขึ้นในขณะใช้งานในโครงการซอฟต์แวร์ขนาดใหญ่ได้อย่างไร ในช่วงสามสัปดาห์ที่ผ่านมาฉันพยายามเริ่มส่วนประกอบของซอฟต์แวร์ชิ้นใหญ่ภายในส่วนประกอบอื่นของซอฟต์แวร์ แต่เป็นระยะ ๆ จะตายเนื่องจากปัญหาการพึ่งพาสกรรมกริยาซึ่งเป็นที่รู้จักกันในเวลาทำงานเท่านั้น โดยปัญหาการพึ่งพาสกรรมกริยาฉันหมายความว่าการอ้างอิงบางอย่างของการอ้างอิงของโครงการที่กำหนดชนกับการพึ่งพาอื่น ๆ ในเวลาทำงานทำให้เกิดความไม่แน่นอนหรือความล้มเหลวทันที มีหลายร้อยคนต่อการใช้งานหลายร้อยคนและมีโครงการย่อยประมาณ 50 โครงการที่เชื่อมโยงกับเครื่องมือที่ทำงานแยกจากทีมอื่น ๆ โดยที่โมดูลทั้งหมดมีการพึ่งพาซ้อนกันระหว่างกันอย่างลึกซึ้ง ไม่มีใครรู้ว่าโครงการย่อยทั้งหมดจะถูกใช้เพื่อกำหนดขนาดและความซับซ้อนของโครงการ ในสถานการณ์นี้คุณจะพยายามสร้างการแสดงภาพของ DAG สำหรับแต่ละการพึ่งพาของส่วนประกอบที่ได้รับผลกระทบและพยายามกำหนดตำแหน่งที่อาจเกิดการชนในเวลาทำงานหรือไม่ ฉันไม่สามารถควบคุมวิธีการจัดการการพึ่งพาในโครงการย่อยอื่น ๆ และไม่สามารถเปลี่ยนรหัส Java ใด ๆ ที่เขียนโดยนักพัฒนาอื่น ๆ วิธีแก้ปัญหาที่ฉันเกิดขึ้นกับการทำงานเพียงหนึ่งชั่วโมงหรือสองชั่วโมงจากนั้นพวกเขาก็หยุดทำงานเนื่องจากการเปลี่ยนแปลงส่วนประกอบต้นน้ำ ตัวอย่างขององค์ประกอบต้นน้ำคือสิ่งประดิษฐ์ที่โครงการที่ฉันกำลังทำงานนั้นขึ้นอยู่กับสิ่งที่ถูกสร้างขึ้นในขั้นตอนก่อนหน้านี้ใน CI ไปป์ไลน์ ตามคำขอของผู้อื่นฉันจะรวมข้อมูลเกี่ยวกับเทคโนโลยีที่ใช้อยู่ในความเสี่ยงที่จะต้องปิดคำถามเพื่อให้ข้อมูลมากเกินไปหรือร่างกายมีความยาวมากเกินไป: Maven ใช้สำหรับการจัดการการพึ่งพา และ สปริงใช้เป็นภาชนะ DI ส่วนใหญ่ของปัญหาการพึ่งพาเกี่ยวข้องกับบริบทถั่วที่ทับซ้อนกันเป็นผลมาจากบริบทของโมดูลอื่น ๆ ที่ถูกโหลดในเวลาทำงาน ผลิตภัณฑ์ทำงานอย่างถูกต้องและมี smorgasbords ของการทดสอบหน่วยและการทดสอบการรวมเพื่อหลีกเลี่ยงความถูกต้องการทำงานของโปรแกรม โดยทั่วไปฉันกำลังมองหาวิธีใช้ภาษาที่ไม่เชื่อเรื่องพระเจ้าในการระบุวิธีการแก้ไขความขัดแย้งในการพึ่งพาโดยไม่ต้องระบุถึงการรวมกันที่เป็นไปได้ทั้งหมดของการขึ้นต่อกันของโครงการ ฉันไม่สามารถสร้างโครงการใหม่เพิ่มประตูคุณภาพเพิ่มเติมผลักดันกระบวนทัศน์ใน …

9 dependency-management  dependency-analysis 

Apache มีเครื่องมือสองแบบแยก: Apache Maven Apache Ant + Apache Ivy พวกเขาดูเหมือนจะเติมทั้งช่องเดียวกัน ฉันมีสองคำถาม: สิ่งที่เป็นไฮไลท์ของความแตกต่างที่สำคัญระหว่างสองเครื่องมือ? ฉันแน่ใจว่าบทความที่ยาวมาก ๆ สามารถเขียนได้เกี่ยวกับความแตกต่างระหว่างสองเรื่องนี้ฉันไม่ได้มองหารายละเอียดมากขนาดนั้นหรือฉันกำลังมองหาข้อโต้แย้งแบบอัตนัยในการเลือกข้อใดข้อหนึ่ง ประวัติความเป็นมาของการเขียนโปรแกรม - มันเกิดขึ้นได้อย่างไรว่า Apache พัฒนาขึ้นเพื่อสร้างเครื่องมือสองชุดที่แยกจากกันโดยสิ้นเชิง

9 history  builds  dependency-management 

ขณะนี้ฉันกำลังพยายามสร้างกรณีสำหรับการใช้การจัดการการพึ่งพาสำหรับการสร้าง (ala Maven, Ivy, NuGet) และสร้างที่เก็บภายในสำหรับโมดูลที่ใช้ร่วมกันซึ่งเรามีองค์กรมากกว่าโหล จุดขายหลักของเทคนิคการสร้างนี้คืออะไร? สิ่งที่ฉันมี: ทำให้กระบวนการแจกจ่ายและนำเข้าโมดูลที่ใช้ร่วมกันโดยเฉพาะการอัพเกรดเวอร์ชั่น ต้องมีการขึ้นต่อกันของโมดูลที่ใช้ร่วมกัน ลบที่ใช้ร่วมกันโมดูลจากการควบคุมแหล่งเร่งและลดความซับซ้อนจ่ายเงิน / เช็คอิน(เมื่อคุณมีการใช้งานกับ 20 + ห้องสมุดนี้เป็นปัจจัยที่แท้จริง) อนุญาตให้ควบคุมหรือรับรู้ถึงสิ่งที่ libs ของบุคคลที่สามที่ใช้ในองค์กรของคุณ มีจุดขายใดที่ฉันขาดหายไปหรือไม่? มีการศึกษาหรือบทความใดบ้างที่ให้ตัวชี้วัดการปรับปรุง?

9 dependency-management