सकर्मक निर्भरताओं में संघर्ष का संकल्प - अच्छा, बुरा, बुराई

इसके बजाय अग्रदूत

अगले शनिवार, एवगेनीबोरिसोव और मैं सेंट पीटर्सबर्ग में JUG.ru पर प्रदर्शन करेंगे। बहुत सारी मज़ेदार ट्रैश और दिलचस्प जानकारी होगी (कभी-कभी आप यह पता लगा सकते हैं कि बॉर्डर कहाँ जाता है), और मेरा एक भाषण मॉड्यूलर प्रोग्राम डेवलपमेंट के डब्ल्यूटीएफ-स्टाइल को समर्पित होगा। मैं आपको कुछ डरावनी फिल्में बताऊंगा, जिनमें से एक इस बारे में होगी कि कैसे हर कोई परियोजना में निर्भरता का शीघ्रता से, लचीले ढंग से और सही ढंग से वर्णन करता है और आमतौर पर इसके बारे में क्या कहता है। रुचि रखते हैं? फिर नरक में आपका स्वागत है!


बल्कि, निश्चित रूप से, "अच्छा, आरामदायक और डब्ल्यूटीएफ-वें।"

सिद्धांत का एक सा ...

एक निर्भरता प्रबंधक क्या है और इसकी आवश्यकता क्यों है?

किसी भी आधुनिक बिल्ड टूल (विशेष रूप से जेवीएम दुनिया में) में उर्फ ​​निर्भरता प्रबंधक शामिल है (या एक आसान-से-कनेक्ट है)। सबसे प्रसिद्ध, निश्चित रूप से, अपाचे मावेन , अपाचे आइवी (अपाचे चींटी के लिए निर्भरता प्रबंधक), और ग्रैडल हैं ।
जेवीएम दुनिया में निर्माण उपकरणों के मुख्य कार्यों में से एक क्लासपैथ बनाना है। उनका उपयोग विधानसभा प्रक्रिया के दौरान बहुत किया जाता है - जहां कोड संकलित करने के लिए, परीक्षण चलाने के लिए, अभिलेखागार (युद्ध, कान, या वितरण और इंस्टॉलर) बनाने के लिए, और यहां तक ​​कि आईडीई में परियोजनाएं स्थापित करने के लिए।
निर्भरता को नेटवर्क खोजने, डाउनलोड करने, भंडारण और कॉन्फ़िगर करने की प्रक्रिया को सुविधाजनक बनाने के लिए, निर्भरता प्रबंधक हैं। आप घोषणा करते हैं कि आपको जरूरत है, उदाहरण के लिए, commons-lang , और वॉइला, आपके पास है।

सकर्मक निर्भरताएँ क्या हैं?

सकर्मक निर्भरता वह कलाकृति है जिस पर परियोजना की प्रत्यक्ष निर्भरता निर्भर करती है। निम्नलिखित स्थिति की कल्पना करें:

हमारी परियोजना A दो कलाकृतियों पर निर्भर करती है - E और B इस पर, प्रत्यक्ष निर्भरताएं समाप्त होती हैं और सकर्मक ( C, D ) शुरू होती हैं। नतीजतन, हमें निर्भरता की श्रृंखला मिलती है जिसमें कलाकृतियों को दोहराया जा सकता है ( D , हमारे उदाहरण में)

हमें सकर्मक निर्भरता की आवश्यकता क्यों है?

जाहिर है संकलन के लिए नहीं। लेकिन, बाकी सब के लिए, शायद, उन्हें ज़रूरत है - ये कलाकृतियां संग्रह सभाओं में होनी चाहिए, परीक्षण चलाने के लिए उन्हें क्लासपाथ में होना चाहिए, और आईडीई के साथ एकीकरण के लिए एपीआई के माध्यम से उन्हें रास्ते दिए जाने चाहिए।

संघर्ष कैसे हो सकता है?

यदि हम ऊपर दिए गए चित्र को देखते हैं, तो हम बहुत संघर्ष देखेंगे। प्रोजेक्ट A क्लासपाथ में दोनों विरूपण साक्ष्य D संस्करण 1 (ई इस पर निर्भर करता है) और विरूपण साक्ष्य D संस्करण 2 ( C इस पर निर्भर करता है) होना चाहिए!

यह बुरा क्यों है?

JVM (और javac) एक वर्ग की विशिष्टता को उसके नाम से निर्धारित करता है (और क्लास लोडर, लेकिन हमारे सरल उदाहरण में, सभी कक्षाएं एक क्लास लोडर के साथ भरी हुई हैं)। मामले में जब क्लासपैथ में एक ही नाम के दो वर्ग पाए जाते हैं, केवल पहले एक को लोड किया जाएगा। यदि हम मानते हैं कि D1 और D2 में एक ही नाम वाली कक्षाएं हैं (आपको सहमत होना चाहिए, तो सबसे अधिक संभावना है), तो जार से वर्ग, जो कि उत्पन्न क्लासपैथ में पंजीकृत होगा, बस दूसरे द्वारा लोड नहीं किया जाएगा। पहला कौन सा होगा? यह निर्भरता प्रबंधक के तर्क पर निर्भर करता है और, सामान्य रूप से, अज्ञात है।
जैसा कि आप जानते हैं, यह एक संघर्ष है:

क्या करें?

यह स्पष्ट है कि किसे दोष देना है (Java, जिनके बारे में आपने नहीं सोचा था), लेकिन क्या किया जा सकता है?
सकर्मक निर्भरताओं में संघर्ष को हल करने के लिए कई रणनीतियां हैं (उनमें से कुछ तार्किक हैं, अन्य बेतुके हैं), लेकिन, निश्चित रूप से, कोई चांदी की गोली नहीं है। आइए उनमें से कुछ को देखें:

• नवीनतम । नवीनतम रणनीति से तात्पर्य पिछड़ी अनुकूलता से है। यदि D2 D1 के साथ पूरी तरह से संगत है, तो क्लासपैथ में केवल नए विरूपण साक्ष्य (D2) को छोड़कर, हमें C का सही संचालन मिलता है (आखिरकार, इसे D2 के तहत लिखा गया है), लेकिन E का सही संचालन भी (क्योंकि यदि D2 पिछड़े संगत है, तो यह उसी तरह काम करता है) डी 1 के समान, जो कि ई के तहत लिखा गया है)। यह रणनीति दो उप-प्रजातियों की है - संस्करण में नवीनतम, और नवीनतम तारीख में। ज्यादातर अक्सर वे उसी तरह से काम करेंगे (उन मामलों को छोड़कर, जिनमें वे नहीं हैं)।
  हमारे उदाहरण के मामले में, क्लासपाथ में नवीनतम का उपयोग करके डी 2 हो जाएगा।
• असफल (उर्फ सख्त)। इस रणनीति के साथ, विधानसभा क्रैश हो जाएगी जब निर्भरता प्रबंधक एक संघर्ष का पता लगाता है। स्वाभाविक रूप से, सबसे सुरक्षित, लेकिन सबसे अधिक समय लेने वाली रणनीति भी।
  हमारे उदाहरण के मामले में, जब असफल का उपयोग करते हैं, तो विधानसभा विफल हो जाएगी।
• सभी (उर्फ नो-संघर्ष)। "वह और एक और, और यह रोटी के बिना संभव है" इसका मतलब है कि हमारे उदाहरण से डी 1 और डी 2 दोनों एक क्लासपाथ (किसी भी क्रम में) में दिखाई देंगे। नरक? नरक! लेकिन अगर क्लासपैथ आइसोलेशन टेक्नोलॉजी का उपयोग किया जाता है (विभिन्न क्लास लोडर के साथ अलग-अलग मॉड्यूल लोड करके), यह न केवल उपयोगी हो सकता है, बल्कि आवश्यक भी हो सकता है।
  हमारे उदाहरण के मामले में, क्लासपाथ में सभी का उपयोग करना डी 1 और डी 2 दोनों हो जाएगा।
• सबसे निकट । "निकटतम" रणनीति पूरी तरह से और पूरी तरह से शानदार डब्ल्यूटीएफ है, जिसके बारे में मुझे नीचे बात करने में खुशी होगी। देखते रहो।
• कस्टम। इस मामले में, निर्भरता प्रबंधक आपसे पूछेगा कि मास्टर क्या संकेत देता है। यह, निश्चित रूप से, "मैनुअल कंट्रोल" है, लेकिन कभी-कभी यह बहुत उपयोगी हो सकता है। यहाँ छद्म-खांचे पर छद्म कोड का एक उदाहरण दिया गया है:
  

   coflictManager = {artifact, versionA, versionB -> //,        Apache,    if(artifact.org.startsWith ('org.apache')){ [versionA, versionB].max() } else { fail() } } 

  
  हमारे उदाहरण के मामले में, इस कस्टम कार्यान्वयन का उपयोग करते समय, यदि हम मानते हैं कि D1 और D2 के लिए org 'org.apache' से शुरू होता है, तो D2 क्लासपाथ में दिखाई देगा, अन्यथा, असेंबली विफल हो जाएगी।
  

कौन क्या है?

अब देखते हैं कि कौन से डेर ग्रोसे ट्रोइका उपर्युक्त हैं जो कर सकते हैं।

अपाचे आइवी

संघर्ष प्रबंधकों के संदर्भ में , आइवी अद्भुत है। वे प्लग-इन हैं, दोनों विकल्प नवीनतम हैं, साथ ही असफल हैं और सभी बॉक्स में जाते हैं। रिवाज के साथ, सब कुछ सुंदर भी है। आप अपने तर्क को पूरी तरह से लागू कर सकते हैं, या आप एक अर्ध-तैयार उत्पाद का उपयोग कर सकते हैं और बस एक उपयुक्त रेगेक्स के साथ आ सकते हैं। डिफ़ॉल्ट रूप से, नवीनतम चल रहा है (संस्करण)।

Gradle

ग्रैडल के पहले संस्करणों में (0.6 से पहले, अगर मेरी मेमोरी मुझे सही सेवा देती है) आइवी को एक निर्भरता प्रबंधक के रूप में इस्तेमाल किया गया था। तदनुसार, उपरोक्त सभी ग्रैडल के लिए भी सच था, लेकिन ग्रैडलवेयर के लोगों ने अपने निर्भरता प्रबंधक को लिखा (मुख्य रूप से समानांतर विधानसभा के दौरान आइवी स्थानीय भंडारण के साथ समस्याओं के कारण, ग्रैडल के मुख्य लाभों में से एक)। अपने प्रबंधक को रिहा करने की प्रक्रिया में, संघर्ष प्रबंधक को बदलने के रूप में इस तरह की "मामूली" सुविधाओं को रोडमैप में बहुत दूर धकेल दिया गया था, और काफी समय तक ग्रैडल केवल नवीनतम के साथ मौजूद था। मुझे नवीनतम पसंद नहीं है - सकर्मक निर्भरता को बंद करें, और आगे बढ़ें, सब कुछ मैन्युअल रूप से सूचीबद्ध करें। लेकिन आज सब कुछ क्रम में है। 1.0 से शुरू करना विफल रहता है , और 1.4 के साथ, कस्टम भी।

अपाचे मावेन

खैर, निम्नलिखित चित्र के लिए, पूरे पोस्ट की कल्पना की गई थी।
D का कौन सा संस्करण आपको लगता है कि कक्षापथ में आएगा? डी 1? डी 2? दोनों? एक नहीं? क्या विधानसभा गिर जाएगी?

जैसा कि आप शायद पहले से ही अनुमान लगा चुके हैं, डी 1 क्लासपाथ में गिर जाएगा (जो समस्याओं के लिए बहुत संभावना है, क्योंकि सी में सभी कोड नई कार्यक्षमता के लिए लिखे गए हैं जो डी 1 में मौजूद नहीं हैं) बस गिर जाएंगे। यह अद्भुत डब्ल्यूटीएफ है जो मैंने आपसे वादा किया था। मावेन अद्वितीय निकटतम रणनीति के साथ काम करता है, जो क्लासपाथ में विरूपण साक्ष्य का चयन करता है जो परियोजना के पेड़ में परियोजना (ए) की जड़ के करीब है।

ऐसा कैसे? क्या बकवास है?

समस्या की जड़ मावेन में निर्भरता को खत्म करने की कठिनाई में है। यदि, उदाहरण के लिए, आप D2 का उपयोग करना चाहते हैं, D1 का नहीं, तो अच्छे के लिए, आपको मावेन को बताना चाहिए: डियर मावेन, कभी भी D1 का उपयोग न करें। एक उदाहरण के रूप में, ग्रैडल में हम इस तरह से लिखेंगे:

 configurations {all*.exclude group: 'mygroup', module: 'D', version: '1'} 

समस्या यह है कि मावेन में इसे व्यक्त करना असंभव है। (मावेन का एक अनुभवी और इसलिए चौकस और विचारशील उपयोगकर्ता यहाँ "एक enfor- प्लगइन के बारे में क्या?" बहाना होगा और यह गलत होगा)। हम विशेष रूप से ई को मॉड्यूल कह सकते हैं: "क्या आपको लगता है कि आपके पास डी पर निर्भरता है? इसलिए, वह वहां नहीं है। " यह एक अच्छा तरीका है, अधिक संघर्ष नहीं है, डी 2 क्लासपाथ में, जीत। लेकिन यह समाधान पूरी तरह से स्केलेबल है। क्या होगा अगर दर्जनों कलाकृतियां डी 1 पर निर्भर करती हैं? परिवर्तनशीलता के विभिन्न स्तरों पर?

खैर, और कहाँ निकटतम है?

वैश्विक बहिष्कृत की अनुपस्थिति की समस्या को मावेन में बहुत "रोचक" तरीके से हल किया गया था। यह तय किया गया था कि यदि आप एक विशिष्ट संस्करण के साथ अपनी परियोजना ए में निर्भरता की घोषणा करते हैं, तो केवल यह संस्करण क्लासपाथ में गिर जाएगा। यही है, व्यवहार में, यह अंतिम निकटतम है - यह ए (यह जड़ है) की तुलना में करीब नहीं हो सकता है, इसलिए संघर्ष हल हो गया है, आपको उन सभी स्थानों की तलाश करने की आवश्यकता नहीं है जहां आपको डी को बाहर करने की आवश्यकता है, हालांकि, व्यवहार की भविष्यवाणी करने के लिए हमें बहुत अजीब और मुश्किल है। ऐसे मामले जहां ए सीधे डी की घोषणा नहीं करता है (हमारे उदाहरण देखें), लेकिन वह यह है कि।

दिलचस्प रूप से पर्याप्त है, "उपयोगकर्ता ने खुद को कानून घोषित किया है" के विचार का उपयोग ग्रैडल में भी किया जाता है, और यह उन्हें नवीनतम जैसी सेंस स्ट्रैटेजी का उपयोग करने से नहीं रोकता है और बाकी सभी चीजों के लिए असफल हो जाता है।

अपडेट: टिप्पणियों में कई लोगों ने याद किया कि एन्फोर्सर-प्लगइन की कार्यक्षमता में विफलता है। यह आंशिक रूप से समस्या को हल करता है। रहता है: 1. डिफ़ॉल्ट रूप से निकटतम जंगली। 2. समस्या का समाधान - अपनी परियोजना में सभी परस्पर निर्भरता (सहिष्णुता), या अंतहीन बहिष्कृत (नरक) को पंजीकृत करने के लिए।

और अगर एक ही गहराई?

यह खूबसूरत सवाल (अगर हमारे उदाहरण बी में डी 2 पर निर्भर हो तो क्या करना है) ढाई साल से (अप्रैल 2005 में रिलीज 2.0 से अप्रैल 2008 में संस्करण 2.0.9 तक) मावेन के लोग नहीं हुए थे और क्लासपैथ में क्या कलाकृतियां होंगी, यह सिर्फ अस्पष्ट था। मावेन 2.0.9 में एक मजबूत इरादों वाला निर्णय किया गया था - पहला होगा!

यह हमें कैसे मदद करता है? यह सही है, कुछ भी नहीं। क्योंकि सामान्य स्थिति में, हम यह नहीं जानते हैं कि कौन सा पहला होगा, क्योंकि संक्रमणकारी निर्भरताएं तब तक खुद को प्रकट नहीं करती हैं जब तक कि कोई संघर्ष नहीं होता (या जब तक हम इस पहेली की जांच शुरू नहीं करते)। धन्यवाद दोस्तों!

एक उपसंहार के बजाय

मावेन की डब्ल्यूटीएफ अंतर्दृष्टि, निश्चित रूप से, वैकल्पिक दिमाग की चमत्कारी पीढ़ी तक सीमित नहीं है - निकटतम रणनीति। लेकिन आज के लिए, मुझे लगता है कि यह काफी है। टिप्पणियों में होलीवरों का बहुत स्वागत है (यदि कुछ भी हो, तो मैं ग्रैडल के लिए डूबूंगा), और सभी पीटर्सबर्ग शनिवार को पेटूकांग्रेस के 31 वें भोज को जारी रखने के लिए JUG में आए।