बहु-रिलीज जार - खराब या अच्छा?

एक अनुवादक से: हम जावा 11 रेल पर प्लेटफॉर्म का अनुवाद करने के लिए सक्रिय रूप से काम कर रहे हैं और इस बारे में सोच रहे हैं कि जावा पुस्तकालयों (जैसे कि YARG ) को कुशलता से कैसे विकसित किया जाए , जावा 8/11 की विशेषताओं को ध्यान में रखते हुए, ताकि आपको अलग-अलग शाखाएँ और रिलीज़ न करने पड़ें । एक संभव समाधान एक बहु-रिलीज JAR है, लेकिन सब कुछ चिकना नहीं है।

जावा 9 में एक नया जावा रनटाइम विकल्प शामिल है जिसे मल्टी-रिलीज़ जार कहा जाता है। यह शायद मंच में सबसे विवादास्पद नवाचारों में से एक है। टीएल; डीआर: हम इसे एक गंभीर समस्या का कुटिल समाधान पाते हैं । इस पोस्ट में हम बताएंगे कि हम ऐसा क्यों सोचते हैं, और यह भी बताएं कि अगर आप वास्तव में चाहते हैं तो ऐसे JAR का निर्माण कैसे करें।

मल्टी-रिलीज़ JAR , या MR JARs, जावा प्लेटफ़ॉर्म की एक नई विशेषता है, जिसे JDK 9 में पेश किया गया है। यहाँ हम इस तकनीक का उपयोग करने से जुड़े महत्वपूर्ण जोखिमों का विस्तार से वर्णन करेंगे, और ग्रेडल का उपयोग करके बहु-रिलीज़ JAR कैसे बनाएँ अगर आप अभी भी चाहते हैं।

वास्तव में, एक बहु-रिलीज़ JAR जावा संग्रह है जिसमें रनटाइम के विभिन्न संस्करणों के साथ काम करने के लिए एक ही वर्ग के कई संस्करण शामिल हैं। उदाहरण के लिए, यदि आप JDK 8 में काम कर रहे हैं, तो Java वातावरण JDK 8 के लिए वर्ग संस्करण का उपयोग करेगा, और यदि Java 9 में, Java 9 के लिए संस्करण का उपयोग किया जाता है। इसी प्रकार, यदि संस्करण जावा 10 के भविष्य के रिलीज के लिए बनाया गया है, तो रनटाइम जावा के लिए संस्करण के बजाय इस संस्करण का उपयोग करता है। 9 या डिफ़ॉल्ट संस्करण (जावा 8)।

बिल्ली के नीचे, हम नए जार प्रारूप के उपकरण को समझते हैं और पता लगाते हैं कि क्या यह सब है।

मल्टी-रिलीज़ JAR का उपयोग कब करें

• अनुकूलित रनटाइम। यह उस समस्या का समाधान है जो कई डेवलपर्स का सामना करते हैं: एक एप्लिकेशन विकसित करते समय, यह ज्ञात नहीं है कि इसे किस वातावरण में निष्पादित किया जाएगा। हालाँकि, रनटाइम के कुछ संस्करणों के लिए, आप उसी वर्ग के जेनेरिक संस्करणों को एम्बेड कर सकते हैं। मान लीजिए कि आप जावा की संस्करण संख्या प्रदर्शित करना चाहते हैं जिसमें एप्लिकेशन चल रहा है। Java 9 के लिए, आप Runtime.getVersion पद्धति का उपयोग कर सकते हैं। हालाँकि, यह केवल जावा 9+ में उपलब्ध एक नई विधि है। यदि आपको अन्य रनटाइम्स की जरूरत है, तो जावा 8 कहिए, आपको java.version प्रॉपर्टी को पार्स करना होगा। नतीजतन, आपके पास एक फ़ंक्शन के 2 अलग-अलग कार्यान्वयन होंगे।

• संघर्षशील एपीआई: एपीआई के बीच संघर्ष संकल्प भी एक आम समस्या है। उदाहरण के लिए, आपको दो रनटाइम का समर्थन करने की आवश्यकता है, लेकिन उनमें से एक में एपीआई अपग्रेड किया गया है। इस समस्या के 2 सामान्य समाधान हैं:

  
  
  1. पहला प्रतिबिंब है। उदाहरण के लिए, आप VersionProvider इंटरफ़ेस निर्दिष्ट कर सकते हैं, फिर 2 विशिष्ट कक्षाएं Java8VersionProvider और Java9VersionProvider, और संबंधित वर्ग को रनटाइम में लोड करें (यह मजेदार है कि दो वर्गों के बीच चयन करने के लिए आपको संस्करण संख्या को पार्स करना होगा!)। इस समाधान के लिए विकल्पों में से एक विभिन्न तरीकों के साथ एक एकल वर्ग बनाना है जिसे प्रतिबिंब का उपयोग करना कहा जाता है।
  2. एक अधिक उन्नत समाधान जहां संभव हो वहां विधि हैंडल का उपयोग करना है। सबसे अधिक संभावना है, प्रतिबिंब आपको निरोधात्मक और असुविधाजनक लगेगा, और, सामान्य रूप से, जिस तरह से यह है।
  
  

बहु-रिलीज JARs के लिए ज्ञात विकल्प

दूसरा तरीका, सरल और अधिक समझने योग्य है, विभिन्न रनटाइम के लिए 2 अलग-अलग अभिलेखागार बनाना है। सिद्धांत रूप में, आप IDE में एक ही वर्ग के दो कार्यान्वयन बनाते हैं, और उन्हें 2 अलग-अलग कलाकृतियों में संकलित करना, परीक्षण करना और सही ढंग से पैक करना निर्माण प्रणाली का कार्य है। यह एक दृष्टिकोण है जो कई सालों से अमरूद या स्पॉक में उपयोग किया जाता है। लेकिन यह स्काला जैसी भाषाओं के लिए भी आवश्यक है। और सभी क्योंकि संकलक और रनटाइम के लिए बहुत सारे विकल्प हैं कि द्विआधारी संगतता लगभग अप्राप्य हो जाती है।

लेकिन अलग-अलग JAR अभिलेखागार का उपयोग करने के कई अन्य कारण हैं:

• JAR पैकिंग का एक तरीका है।

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

• यह बहुत अधिक महत्वपूर्ण है कि, एक कलाकृति होने के नाते, एक जार-संग्रह निर्भरता के बारे में जानकारी नहीं ले सकता है।

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

और अंत में, एक परियोजना में आप विभिन्न उद्देश्यों के लिए JAR बना सकते हैं:

• एपीआई के लिए
• जावा के लिए ava
• जावा के लिए ९
• मूल बंधन के साथ
• आदि

निर्भरता के वर्गीकरण का गलत उपयोग एक ही तंत्र के बंटवारे से संबंधित संघर्षों की ओर जाता है। आमतौर पर स्रोत या javadocs classifiers के रूप में स्थापित किए जाते हैं, लेकिन वास्तव में उनकी कोई निर्भरता नहीं है।

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

व्यक्तिगत JAR अभिलेखागार का प्रबंधन करने के लिए अधिक कुशल तरीके

डेवलपर्स द्वारा अलग-अलग अभिलेखागार का उपयोग नहीं करने का मुख्य कारण यह है कि उन्हें इकट्ठा करने और उपयोग करने में असुविधा होती है। बिल्ड टूल को दोष देना है, जो ग्रैडल से पहले था, इसके साथ बिल्कुल भी सामना नहीं किया। विशेष रूप से, जिन्होंने मावेन में इस पद्धति का उपयोग किया, वे केवल अतिरिक्त कलाकृतियों को प्रकाशित करने के लिए कमजोर क्लासिफायर फ़ंक्शन पर भरोसा कर सकते थे। हालांकि, क्लासिफायर इस मुश्किल स्थिति में मदद नहीं करता है। वे विभिन्न उद्देश्यों के लिए उपयोग किए जाते हैं, स्रोत कोड प्रकाशित करने से, प्रलेखन, javadocs, पुस्तकालय विकल्पों को लागू करने के लिए (अमरूद-jdk5, अमरूद-jdk7, ...) या विभिन्न उपयोग के मामले (एपीआई, वसा जार, ...)। व्यवहार में, यह दिखाने का कोई तरीका नहीं है कि क्लासिफायर निर्भरता पेड़ मुख्य परियोजना की निर्भरता पेड़ से अलग है। दूसरे शब्दों में, POM प्रारूप मूल रूप से टूट गया है क्योंकि यह दर्शाता है कि घटक को कैसे इकट्ठा किया जाता है और यह कलाकृतियों की आपूर्ति करता है। मान लें कि आपको 2 अलग-अलग जार अभिलेखागार लागू करने की आवश्यकता है: क्लासिक और वसा जार, जिसमें सभी निर्भरताएं शामिल हैं। मावेन ने फैसला किया कि 2 कलाकृतियों में समान निर्भरता के पेड़ हैं, भले ही यह स्पष्ट रूप से गलत हो! इस मामले में, यह स्पष्ट से अधिक है, लेकिन स्थिति बहु-रिलीज जार के साथ ही है!

इसका उपाय है कि विकल्पों को सही ढंग से संभालना। ग्रेडल विकल्पों के आधार पर निर्भरता का प्रबंधन करके ऐसा कर सकते हैं। यह सुविधा वर्तमान में एंड्रॉइड पर विकास के लिए उपलब्ध है, लेकिन हम जावा और देशी अनुप्रयोगों के लिए इसके संस्करण पर भी काम कर रहे हैं!

वेरिएंट-आधारित निर्भरता प्रबंधन इस तथ्य पर आधारित है कि मॉड्यूल और कलाकृतियां पूरी तरह से अलग चीजें हैं। एक ही कोड विभिन्न रनटाइम में पूरी तरह से काम कर सकता है, विभिन्न आवश्यकताओं को ध्यान में रखकर। उन लोगों के लिए जो मूल संकलन के साथ काम करते हैं, यह लंबे समय से स्पष्ट है: हम i386 और amd64 के लिए संकलन करते हैं और किसी भी तरह से हम i386 पुस्तकालय की निर्भरता में arm64 के साथ हस्तक्षेप नहीं कर सकते हैं! जावा के संदर्भ में, इसका मतलब है कि जावा 8 के लिए आपको "जावा 8" जार संग्रह का एक संस्करण बनाने की आवश्यकता है, जहां वर्ग प्रारूप जावा 8 के अनुरूप होगा। इस विरूपण साक्ष्य में मेटाडेटा में जानकारी होगी जिसमें निर्भरता का उपयोग करना है। जावा 8 या 9 के लिए, संस्करण के अनुरूप निर्भरता का चयन किया जाएगा। यह इतना आसान है (वास्तव में, इसका कारण यह नहीं है कि रनटाइम विकल्पों का केवल एक क्षेत्र है, आप कई संयोजन कर सकते हैं)।

बेशक, अत्यधिक जटिलता के कारण पहले किसी ने ऐसा नहीं किया था: मावेन, जाहिरा तौर पर, इस तरह के जटिल ऑपरेशन को कभी भी करने की अनुमति नहीं देगा। लेकिन ग्रैडल के साथ यह संभव है। ग्रैडल टीम वर्तमान में एक नए मेटाडेटा प्रारूप पर काम कर रही है जो उपयोगकर्ताओं को बताता है कि किस विकल्प का उपयोग करना है। सीधे शब्दों में कहें, एक बिल्ड टूल को ऐसे मॉड्यूल के संकलन, परीक्षण, पैकेजिंग और प्रसंस्करण को संभालना चाहिए। उदाहरण के लिए, प्रोजेक्ट को जावा 8 और जावा 9 रनटाइम में काम करना चाहिए। आदर्श रूप से, आपको लाइब्रेरी के 2 संस्करणों को लागू करने की आवश्यकता है। इसका मतलब है कि 2 अलग-अलग संकलक हैं (जावा 8 में काम करते समय जावा 9 एपीआई का उपयोग करने से बचने के लिए), 2 वर्ग निर्देशिका और, अंततः, 2 अलग-अलग जार अभिलेखागार। और यह भी, सबसे अधिक संभावना है, 2 रनटाइम्स का परीक्षण करना आवश्यक होगा। या आप 2 अभिलेखागार को लागू करते हैं, लेकिन जावा 9 रनटाइम में जावा 8 संस्करण के व्यवहार का परीक्षण करने का निर्णय लेते हैं (क्योंकि यह स्टार्टअप पर हो सकता है!)।

यह योजना अभी तक लागू नहीं हुई है, लेकिन ग्रैडल टीम ने इस दिशा में महत्वपूर्ण प्रगति की है।

ग्रैडल का उपयोग करके बहु-रिलीज़ जार कैसे बनाएं

लेकिन अगर यह फ़ंक्शन अभी तक तैयार नहीं है, तो मुझे क्या करना चाहिए? आराम, सही कलाकृतियों को उसी तरह बनाया जाता है। जावा पारिस्थितिक तंत्र में उपरोक्त फ़ंक्शन दिखाई देने से पहले, दो विकल्प हैं:

• प्रतिबिंब या विभिन्न जार अभिलेखागार का उपयोग करके अच्छा पुराना तरीका;
• मल्टी-रिलीज़ JARs का उपयोग करें (ध्यान दें कि यह एक बुरा समाधान हो सकता है, भले ही अच्छे उपयोग के मामले हों)।

आप जो भी चुनते हैं, विभिन्न अभिलेखागार या मल्टी-रिलीज़ JARs, योजना एक ही होगी। बहु-रिलीज़ जार अनिवार्य रूप से गलत पैकेजिंग हैं: उन्हें एक विकल्प होना चाहिए, लेकिन लक्ष्य नहीं। तकनीकी रूप से, स्रोत लेआउट व्यक्तिगत और बाहरी JAR के लिए समान है। यह भंडार वर्णन करता है कि ग्रैडल का उपयोग करके एक बहु-रिलीज़ JAR कैसे बनाया जाए। प्रक्रिया का सार संक्षेप में नीचे वर्णित है।

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

एक अन्य मुख्य बिंदु पदनाम सेट है । स्रोत सेट स्रोत फ़ाइलों का एक सेट है जिसे एक साथ संकलित करने की आवश्यकता होती है। एक JAR एक या एक से अधिक स्रोत सेट को संकलित करके प्राप्त किया जाता है। प्रत्येक सेट के लिए, ग्रैडल स्वचालित रूप से एक उपयुक्त कस्टम संकलन कार्य बनाता है। इसका मतलब है कि अगर जावा 8 और जावा 9 के स्रोत हैं, तो ये स्रोत अलग-अलग सेटों में होंगे। यह वास्तव में जावा 9 के लिए निर्धारित स्रोत में काम करता है , जिसमें हमारी कक्षा का एक संस्करण होगा। यह वास्तव में काम करता है, और आपको मावेन की तरह एक अलग परियोजना बनाने की आवश्यकता नहीं है। लेकिन सबसे महत्वपूर्ण बात, यह विधि आपको सेट के संकलन को ठीक करने की अनुमति देती है।

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

अगला चरण सरल है : आपको ग्रैडल को यह समझाने की ज़रूरत है कि स्रोतों का मुख्य सेट जावा 8 एपीआई स्तर के साथ संकलित होगा, और जावा 9 के लिए जावा 9 स्तर के साथ सेट होगा।

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

jar { into('META-INF/versions/9') { from sourceSets.java9.output } manifest.attributes( 'Multi-Release': 'true' ) } 

यह ब्लॉक वर्णन करता है: META-INF / संस्करणों / 9 निर्देशिका में जावा 9 के लिए पैकिंग कक्षाएं, जो एमआर जार के लिए उपयोग की जाती हैं, और प्रकट में मल्टी-रिलीज़ लेबल सेट करती हैं।

और यह बात है, आपका पहला MR JAR तैयार है!

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

और अंतिम लेकिन कम से कम, हमने उल्लेख किया कि हमें कक्षा के 2 संस्करणों का परीक्षण करने की आवश्यकता होगी। इसके लिए, आप एक अलग प्रक्रिया में केवल वीएम का उपयोग कर सकते हैं, क्योंकि जावा रनटाइम के लिए -release मार्कर के बराबर नहीं है। विचार यह है कि केवल एक परीक्षा को लिखने की आवश्यकता है, लेकिन इसे दो बार निष्पादित किया जाएगा: जावा 8 और जावा 9 में। यह सुनिश्चित करने का एकमात्र तरीका है कि रनटाइम-विशिष्ट कक्षाएं सही तरीके से काम करती हैं। डिफ़ॉल्ट रूप से, ग्रैडल एक परीक्षण कार्य बनाता है, और यह JAR के बजाय कक्षा निर्देशिकाओं का उपयोग करता है। इसलिए, हम दो काम करेंगे: जावा 9 के लिए एक परीक्षण कार्य बनाएं और दोनों कार्यों को कॉन्फ़िगर करें ताकि वे JAR और निर्दिष्ट जावा रनटाइम का उपयोग करें। कार्यान्वयन इस तरह दिखेगा:

 test { dependsOn jar def jdkHome = System.getenv("JAVA_8") classpath = files(jar.archivePath, classpath) - sourceSets.main.output executable = file("$jdkHome/bin/java") doFirst { println "$name runs test using JDK 8" } } task testJava9(type: Test) { dependsOn jar def jdkHome = System.getenv("JAVA_9") classpath = files(jar.archivePath, classpath) - sourceSets.main.output executable = file("$jdkHome/bin/java") doFirst { println classpath.asPath println "$name runs test using JDK 9" } } check.dependsOn(testJava9) 

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

निष्कर्ष

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

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