2010-01-13 12 views
11

मैं जावा में एक वेब अनुप्रयोग विकसित कर रहा हूँ और मैं अपने lib फ़ोल्डर में कई तृतीय पक्ष जार फ़ाइलों का उपयोग कर रहा हूँ। मेरे पास सबवर्सन भी मेरे संस्करण नियंत्रण उपकरण के रूप में है।संस्करण नियंत्रण उपकरण में जेएआर फाइलों (पुस्तकालयों) की जांच - क्या यह एक अच्छा अभ्यास है?

मेरा प्रश्न है, जबकि अपने प्रोजेक्ट फाइलों में जाँच, मैं चेक-इन भी जार फ़ाइलों चाहिए या के रूप में मैं उन्हें वैसे भी संशोधित नहीं कर रहा हूँ यह संस्करण के लिए की जरूरत नहीं है जार फ़ाइलों?

उत्तर

9

यह एक सुंदर व्यक्तिपरक प्रश्न है ... मैं आम तौर पर अंगूठे के निम्नलिखित नियम को लागू करता हूं: यदि मेरे पास बाइनरी बनाने के लिए कोड है, तो कोड में जांचें, और बाइनरी कभी नहीं; अगर मेरे कोड को चलाने के लिए बाइनरी की आवश्यकता होती है और यह बाहरी स्रोत से आता है, तो बाइनरी में जांचें।

नोट आप जो कुछ भी कानूनी स्थिति के अनुरूप करने के लिए अपने भंडार को किसी तीसरे पक्ष बाइनरी में जाँच के साथ आ सकते हैं चाहता हूँ कि ..

+0

मुझे नहीं लगता कि कोई कानूनी समस्या है, क्योंकि मैं ज्यादातर ओपन सोर्स लाइब्रेरी का उपयोग कर रहा हूं। हाँ! मैंने सभी जारों की जांच करने का फैसला किया। – Veera

7

मैं सुझाव है कि जहां भी संभव हो, तो आप Maven उपयोग करना चाहिए। फिर आपको अपनी विकास टीम (ज्यादातर समय) में साझा करने के लिए अपने भंडार में तीसरे पक्ष के जारों की जांच करने की आवश्यकता नहीं होगी। स्वचालन और निर्भरता प्रबंधन का निर्माण:

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

+1

यदि आप चींटी के साथ अधिक आरामदायक हैं, तो आइवी अपाचे (http://ant.apache.org/ivy/) को समझना आसान हो सकता है। – notnoop

+3

यह सच है, हालांकि एंटी/आइवी और मेवेन दोनों का उपयोग करने के बाद, मैं अब तक मैवेन पसंद करता हूं। – danben

1

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

मुझे लगता है कि यह अभी भी प्रासंगिक है, लेकिन SVN ऐतिहासिक दृष्टि से बाइनरी के साथ खराब प्रदर्शन किया है। आईबीएम में एक जावा डेवलपर इस मुद्दे में भाग गया, जांच की, और अपने निष्कर्ष लिखे। आप इसे उपयोगी लग सकते:

इस जांच के निष्कर्ष, स्पष्ट रूप से प्रणाली के लिए विशिष्ट जांच की जा रही हैं, तो यह संभावना नहीं है कि पता चला वास्तविक मान हैं:

Performance tuning Subversion: Store and handle binaries without the performance drag

यहाँ टेकअवे है अन्य प्रणालियों के लिए बहुत महत्व के लिए। पैटर्न अधिक महत्वपूर्ण हैं क्योंकि उन्हें किसी भी सबवर्जन सिस्टम में दोहराया जाएगा। हमारे निष्कर्षों के अनुसार, जब सबवर्सन में बाइनरी का एक सेट के भंडारण:

  • सबसे अधिक समय कुशल विधि एक एकल, संपीड़ित फ़ाइल बाइनरी युक्त बनाने के लिए है।
  • सबसे अधिक स्थान-कुशल विधि नियमित निर्देशिका संरचना पर सबवर्जन की कुशल चेक-इन स्क्रिप्ट का उपयोग करना है।
  • सबवर्जन सर्वर पर प्रमाणीकरण के किसी भी रूप का उपयोग करने से प्रदर्शन हानि होगी।
  • एक समर्पित, शक्तिशाली मशीन सबवर्सन चलाने के लिए इष्टतम है।
+0

लिंक 404 अब – koppor

+0

@ कोपर: वेबैकमाचिन बचाव के लिए: खुश 18 लोगों को इस पृष्ठ को बचाने के लिए दूरदर्शिता थी। :) –

2

व्यक्तिगत तौर पर मैं एससीएम संस्करण नियंत्रण भंडार में एक परियोजना के निर्भरता में जाँच से बचने के लिए कोशिश करेंगे।आम तौर पर यह एक अन्य उत्तर में सुझाए गए मेवेन का उपयोग करके और एक कंपनी-आंतरिक मेवेन रिपोजिटरी को तैनात करने के द्वारा किया जाएगा, जिसे इस संसाधन को विकास टीम को स्थानीय बनाने का एक फायदा है और एक ऐसी जगह प्रदान करने के लिए जहां आपकी परियोजना का पूरा/संस्करण/रिलीज कलाकृतियों का निवास हो सके ।

जेर्स के साथ एससीएम होने की समस्या यह है कि सबसे पहले और सबसे महत्वपूर्ण, एससीएम स्रोत कोड के प्रबंधन के लिए है और उन्हें उस उद्देश्य के लिए अनुकूलित किया गया है। संकलित कलाकृतियों स्रोत कोड नहीं होते हैं और बाइनरी होते हैं, जब आप आम तौर पर बाइनरी को शाखा या अद्यतन करते हैं तो आप बाइनरी की एक प्रति बना रहे हैं, क्योंकि अधिकांश एससीएम बाइनरी फ़ाइल को 'diff' नहीं कर सकते हैं।

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

तीसरा, आप इंटर-प्रोजेक्ट निर्भरताओं का प्रबंधन कैसे करते हैं (जहां आपकी परियोजनाओं में से कोई एक दूसरे पर निर्भर करता है)? क्या एक से जार फ़ाइल दूसरे में चेक की गई है? संस्करण और अन्य परिवर्तन नियंत्रण के बारे में क्या? क्या आपको सिर्फ दो परियोजनाओं की जांच करनी है और उन्हें सख्त क्रम में निर्मित करने की आवश्यकता है?

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

संबंधित मुद्दे