बड़े जावा सिस्टम निर्भरता प्रबंधन

Question

हमारे पास एक बड़ी (> 500,000 LOC) जावा सिस्टम है जो 40-50 OSS पैकेज पर निर्भर करता है। सिस्टम चींटी के साथ बनाया गया है, और निर्भरता प्रबंधन वर्तमान में मैन्युअल रूप से संभाला जाता है। मैं स्वचालित निर्भरताओं के लिए आइवी और/या मेवेन की जांच कर रहा हूं। हमने पिछले साल एक स्वचालन प्रणाली के निर्माण के रूप में मेवेन को देखा और इसे अस्वीकार कर दिया क्योंकि इसे मेवेन के आर्किटेक्चर से मेल खाने के लिए पूरी तरह से हमारे सिस्टम को पुनर्गठन की आवश्यकता होगी। अब मैं निर्भरता प्रबंधन कार्यों को स्वचालित करने के लिए देख रहा हूं।

मैंने आइवी के साथ कुछ प्रयोग किया है लेकिन समस्याओं में भाग लिया है। उदाहरण के लिए, जब मैं एक्टिवएमक्यू को निर्भरता के रूप में निर्दिष्ट करता हूं, और आइवी को पर निर्भर करता हूं, निर्भरता विनिर्देश के लिए मेवेन रिपॉजिटरी में पीओएम का उपयोग करें, आइवी पैकेजों का एक गुच्छा पुनर्प्राप्त करता है (जेटी, डर्बी और गेरोनिमो उदाहरण के लिए) जो मुझे पता है ' केवल ActiveMQ का उपयोग करने की आवश्यकता नहीं है।

अगर मैं सेट usepoms = "false" ivysettings.xml में यह केवल activemq.jar को हासिल करेगा, लेकिन वह आइवी का उद्देश्य विफल हो रहा है और मैन्युअल रूप से बनाया निर्भरता विशिष्टताओं के साथ एक सरल जार-फ़ेचर को यह relegates ।

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

मुझे लगता है कि यह सभी पैकेज की निर्भरता विनिर्देश (पीओएम) की गुणवत्ता के लिए उबाल जाता है। ActiveMQ के मामले में, कोई स्कोप घोषणाएं नहीं हैं, इसलिए ActiveMQ का कोई भी संदर्भ इसकी सभी निर्भरताओं को डाउनलोड करेगा जब तक कि हम उन लोगों को मैन्युअल रूप से बहिष्कृत नहीं करते जिन्हें हम जानते हैं कि हम नहीं चाहते हैं।

log4j के मामले में, स्वचालित निर्भरता संकल्प की आवश्यकता होगी कि log4j के ग्राहकों (अन्य संकुल कि log4j पर निर्भर करते हैं) log4j के सभी पूर्व संस्करण के खिलाफ सत्यापित करें और संगत log4j संस्करणों की एक सीमा (या सूची) प्रदान के सभी पीओएम में यह शायद पूछने के लिए बहुत कुछ है।

क्या यह वर्तमान स्थिति है, या क्या मुझे कुछ याद आ रही है?

Answer 1

की तुलना में खराब या बुरा के रूप में मेटा डेटा है कि

मुझे लगता है कि यह सभी प्रत्येक पैकेज की निर्भरता विनिर्देश (पीओएम) की गुणवत्ता के लिए उबाल जाता है।

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

आखिरकार, लॉग 4j संस्करण को ध्यान में रखते हुए, क्या आपके पास बाहरी निर्भरताएं संस्करण चुनती हैं या आपके द्वारा काम किए जाने वाले संस्करण का चयन करते हैं?

---

कैसे आप दर्जी निर्भरता के लिए चुन सकते का सवाल है, यहाँ क्या आप आइवी के साथ क्या कर सकते हैं:

अनावश्यक संकुल

आइवी पैकेज (घाट, के लिए डर्बी और Geronimo का एक समूह को पुन: प्राप्त उदाहरण) जो मुझे पता है कि केवल ActiveMQ का उपयोग करने के लिए आवश्यक नहीं है।

यह आमतौर पर आवेदन में खराब मॉड्यूलरिटी के कारण होता है। आवेदन के कुछ भाग उदाहरण के लिए जेटी की आवश्यकता है, लेकिन यदि आप इसका उपयोग नहीं करते हैं तो भी आप इस संक्रमणीय निर्भरता के साथ समाप्त हो जाते हैं। इसलिए निर्भरता संकल्प मैन्युअल रूप से निर्धारित करने में शामिल संस्करण के साथ संगत है जो,

<dependency name="A" rev="1.0"> 
    <exclude module="B"/> 
</dependency> 

निर्भरता संस्करणों

केवल एक log4j.jar classpath में हो सकता है:

आप शायद ivy exclude mechanism में देखना चाहते हैं हमारे सिस्टम में अपने सभी ग्राहक।

शायद मैं इस ग़लत व्याख्या कर रहा हूँ, लेकिन कोई मैनुअल आइवी के संघर्ष समाधान में तत्व है।

• सभी:: वहाँ default conflict managers की एक सूची है यह सब संशोधन का चयन करके प्रबंधक संकल्प संघर्ष विरोध करता है। NoConflictManager भी कहा जाता है, यह किसी भी मॉड्यूल को बेदखल करता है।
• नवीनतम समय: यह संघर्ष प्रबंधक केवल 'नवीनतम' संशोधन का चयन करता है, जिसे नवीनतम समय के रूप में परिभाषित किया जा रहा है। ध्यान दें कि समय में नवीनतम गणना करने के लिए महंगा है, इसलिए यदि आप कर सकते हैं तो नवीनतम संशोधन को प्राथमिकता दें।
• नवीनतम संशोधन: यह संघर्ष प्रबंधक केवल 'नवीनतम' संशोधन का चयन करता है, नवीनतम संशोधनों की एक स्ट्रिंग तुलना द्वारा परिभाषित किया जा रहा है।
• नवीनतम-अनुकूल: यह संघर्ष प्रबंधक संघर्षों में नवीनतम संस्करण का चयन करता है जिसके परिणामस्वरूप निर्भरता का एक संगत सेट हो सकता है। इसका मतलब यह है कि अंत में यह संघर्ष प्रबंधक किसी भी संघर्ष (सख्त संघर्ष प्रबंधक की तरह) की अनुमति नहीं देता है, सिवाय इसके कि यह संगत मॉड्यूल (संस्करण बाधाओं के अनुसार) के सेट को खोजने का प्रयास करने के लिए सर्वोत्तम प्रयास रणनीति का पालन करता है;
• सख्त: जब भी कोई संघर्ष मिलता है तो यह संघर्ष प्रबंधक एक अपवाद फेंकता है (यानी निर्माण विफलता का कारण बनता है)।

यदि आवश्यक हो, तो आप provide your own conflict manager कर सकते हैं।

Answer 2

हाँ "इस मामलों की वर्तमान स्थिति है"।

यह ओपन-सोर्स ट्रेडऑफ है।

एक बंद-स्रोत ढांचा (यानी, नेट) आपके लिए यह सब हल करेगा।

एक ओपन सोर्स समाधान का मतलब है कि आपको इसे हर समय हल करना होगा (और इसे हल करना)।

आप कुछ पूर्व-निर्मित कॉन्फ़िगरेशन ढूंढने में सक्षम हो सकते हैं और उन्हें अद्यतित रखने के लिए किसी को भुगतान कर सकते हैं। उदाहरण के लिए, आप Red Hat Enterprise Linux का उपयोग करने के लिए चुन सकते हैं। यदि आप ठीक से चिपकते हैं जो वे समर्थन करते हैं (और कुछ और नहीं) तो कॉन्फ़िगरेशन हल हो जाता है।

बाधाएं अच्छी हैं, हालांकि, कोई पैक कॉन्फ़िगरेशन आपकी आवश्यकताओं को पूरा नहीं करता है।

Answer 3

मुझे लगता है कि यह वास्तव में मामलों की वर्तमान स्थिति है। OSGi और जावा 1.7 के लिए प्रस्तावित नई पैकेजिंग प्रणाली (उस पर चर्चा पहले से ही एक निष्कर्ष पर आ गई है?) कम से कम अलग-अलग-संस्करण-के-पुस्तकालय मुद्दे को ठीक करने पर प्रयास कर रहे हैं, लेकिन मैं नहीं करता लगता है कि वे अभी आपकी समस्या को ठीक करने में सक्षम होंगे।

Answer 4

"क्या यह वर्तमान स्थिति है?"

ओएसजीआई के साथ नहीं। आप ओएसजीआई कंटेनर और बंडलों को देखना चाह सकते हैं। एक बंडल एक जार फ़ाइल की तरह है, लेकिन यह मेटा डेटा का समर्थन करता है जो इसके संस्करण का विवरण देता है, और इसके संबंधित बंडलों के संस्करणों की आवश्यकता होती है (मेटा-आईएनएफ फ़ाइल में विशेषताओं को डालकर)। तो आपका log4j बंडल इसके संस्करण को इंगित करेगा, और आश्रित बंडल विस्तार से लॉग 4j के संस्करणों के बारे में विस्तार करेंगे।

इसके अलावा, एक गैर-श्रेणीबद्ध क्लासलोडर तंत्र समर्थित है, जैसे कि आप log4j के कई संस्करण लोड कर सकते हैं, और विभिन्न बंडल निर्दिष्ट कर सकते हैं, और उन अलग-अलग संस्करणों से जुड़ सकते हैं।

जावावर्ल्ड का बहुत अच्छा परिचय here है।

Answer 5

यह बहुत अधिक है। मेवेन निर्भरता प्रणाली (जो आइवी अधिक या निम्न निम्नानुसार है) इसे अपनी परियोजनाओं के लिए आवश्यक मेटा डेटा जोड़ने का अच्छा काम करने के लिए अलग-अलग परियोजनाओं तक छोड़ देती है। अधिकांश नहीं करते हैं।

यदि आप उस मार्ग पर जाते हैं, तो बहिष्करण की स्थापना करने में समय बिताने की उम्मीद है।

पोस्टर OSGi की सिफारिश करने के लिए, ओ पी ने कहा कि वह Maven के लिए फिर से वास्तुकार उसके निर्माण व्यवस्था करने के लिए, मुझे लगता है कि नहीं होता वह फिर से वास्तुकार के लिए अपने आवेदन OSGi अनुरूप होने के लिए चाहते हो जाएगा तैयार नहीं है। इसके अलावा, ओएसएस परियोजनाओं कि OSGi अनुपालन किया जा रहा है (और वहाँ के रूप में कई आप आशा करता हूँ के रूप में नहीं कर रहे हैं) का एक बहुत तुम कह में पूरी तरह से सही हो Maven

Answer 6

आपकी निर्भरताओं में से optionalactivemq-core पोम में (मेवेन बुक से relevant section भी देखें) को परिभाषित किया गया है।

• org.apache.derby: डर्बी
• org.apache.geronimo.specs: Geronimo-jta_1.0.1B_spec

मैं घाट पर सीधा निर्भरता नहीं देखा था, तो यह हो सकता है वैकल्पिक निर्भरताओं में से एक से संक्रमित रूप से शामिल किया जाना चाहिए।

मेवेन में वैकल्पिक निर्भरता स्वचालित रूप से संभाली जाती है। अनिवार्य रूप से किसी भी निर्भरता को घोषित किया जाना चाहिए जिसे आपके पोम में इस्तेमाल किया जाना चाहिए।उपरोक्त लिंक किए गए दस्तावेज से:

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

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

मुझे यकीन नहीं है कि आप वैकल्पिक निर्भरताओं को अनदेखा करने के लिए आइवी कॉन्फ़िगर कर सकते हैं, लेकिन आप इसे exclude dependencies पर कॉन्फ़िगर कर सकते हैं। उदाहरण के लिए:

<dependency name="A" rev="1.0"> 
    <exclude module="B"/> 
</dependency> 

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

---

आपके प्रश्न के अंतिम भाग के बारे में। मेवेन log4j के लिए निर्भरता संस्करणों को हल करेगा और यदि संस्करण संगत हैं तो यह स्वचालित रूप से सूचीबद्ध संस्करणों के 'निकटतम' का चयन करेगा।

Introduction to the Dependency Mechanism से:

• निर्भरता मध्यस्थता - यह निर्धारित करता है जब एक विरूपण साक्ष्य के कई संस्करण का सामना करना पड़ा कर रहे हैं जो एक निर्भरता के संस्करण इस्तेमाल किया जाएगा। वर्तमान में, मेवेन 2.0 केवल "निकटतम परिभाषा" का उपयोग करने का समर्थन करता है जिसका अर्थ है कि यह निर्भरता के पेड़ में आपकी परियोजना के निकटतम निर्भरता के संस्करण का उपयोग करेगा। आप हमेशा अपने प्रोजेक्ट के पीओएम में इसे स्पष्ट रूप से घोषित करके एक संस्करण की गारंटी दे सकते हैं। ध्यान दें कि यदि निर्भरता पेड़ में दो निर्भरता संस्करण समान गहराई पर हैं, तो मैवेन 2.0.8 तक यह परिभाषित नहीं किया गया था कि कौन सी जीत जाएगा, लेकिन चूंकि मेवेन 2.0.9 यह घोषणा की गई क्रम में ऑर्डर है: पहली घोषणा जीत जाती है।

  • "निकटतम परिभाषा" का अर्थ है कि उपयोग किया गया संस्करण निर्भरता के पेड़ में आपकी परियोजना के सबसे नज़दीक होगा, उदाहरण के लिए। यदि ए, बी, और सी के लिए निर्भरता को ए -> बी -> सी -> डी 2.0 और ए -> ई -> डी 1.0 के रूप में परिभाषित किया गया है, तो डी 1.0 का निर्माण ए के निर्माण के दौरान किया जाएगा क्योंकि ए से डी के माध्यम से पथ ई छोटा है। आप स्पष्ट रूप से डी 2,0

के उपयोग कहाँ संस्करणों संगत आप निर्भरता संकल्प से बड़ी समस्या है नहीं कर रहे हैं के लिए मजबूर करने के लिए एक में विकास 2.0 में एक निर्भरता जोड़ सकते हैं। मेरा मानना ​​है कि आइवी एक समान मॉडल पर काम करता है लेकिन मैं कोई विशेषज्ञ नहीं हूं।

Answer 7

मैं वर्तमान में कई परियोजनाओं (कुछ स्टैंडअलोन, कुछ आश्रितों) के लिए 120 से अधिक ओएसएस और स्वामित्व पुस्तकालयों का प्रबंधन करने के लिए आइवी का उपयोग कर रहा हूं। 2005 में वापस (जब आईवी अभी भी जयसोफ्ट से था) मैंने प्रत्येक एकीकृत पैकेज के लिए ivy.xml फ़ाइलों को लिखने का निर्णय लिया (या करना था)।

सबसे बड़ा फायदा यह है कि मेरे पास विभिन्न कॉन्फ़िगरेशन पर पूर्ण नियंत्रण है। यह कुछ के लिए ओवरकिल लग सकता है लेकिन हमारी बिल्ड सिस्टम अब 4 से अधिक वर्षों से विश्वसनीय रूप से काम कर रही है और एक नई लाइब्रेरी जोड़ने आमतौर पर 5 मिनट का काम है।

Answer 8

निर्भरता इंजेक्शन का पूरा विचार है - जो हमेशा पुनर्गठित होने की आवश्यकता वाले कार्यक्रम की ओर ले जाएगा। मैं इस संबंध में GUICE के बारे में कुछ शोर सुन रहा हूं। तैनाती परिप्रेक्ष्य में मुझे केवल .jar को तैनात करने के साथ उचित सफलता मिली है, जिसे हम निर्भरता के साथ बनाया गया है। जारल के माध्यम से मूल परियोजनाओं से प्राप्त किए जा रहे हैं। इसके पीछे निर्माण प्रणाली निर्भरता के नए संस्करणों के मैन्युअल ट्रैकिंग और निर्माण प्रणाली में अद्यतन करने में शामिल है। प्रयास किए गए समाधानों के साथ इस मुद्दे के स्पष्ट विवरण के लिए