ग्रेजल में पैकेज रीपैकिंग

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

configurations.all { resolutionStrategy { force "org.ow2.asm:asm:7.2" } } 

दुर्भाग्य से, यह हमेशा संस्करण संघर्ष की समस्या को हल करने में मदद नहीं करता है। उदाहरण के लिए, एक ज्ञात समस्या यह है कि फर्मवेयर में कुछ htc उपकरणों में पहले से ही एक gson पुस्तकालय है, और यदि आपके gson का संस्करण बिल्ट-इन से भिन्न है, तो समस्याएँ हो सकती हैं, क्योंकि ClassLoader केवल एक वर्ग को मेमोरी में लोड करेगा, और इस मामले में यह एक सिस्टम होगा।

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

मुझे एक ग्रेड संघर्ष का सामना करना पड़ा जब एक ग्रैडिएंट प्लगइन लिख रहा था, यह एएसएम लाइब्रेरी का उपयोग करता है, जो विवादित था। प्लगइन लिखने के बाद, मैंने एक परीक्षण परियोजना पर इसके प्रदर्शन की जाँच की: सब कुछ ठीक है, एक पालतू परियोजना पर जाँच की, सब कुछ ठीक है, लेकिन जब मैंने इसे तीसरे पक्ष के निर्भरता वाले समूह के साथ एक वास्तविक कार्यशील परियोजना से जोड़ा, तो मैं एक समस्या में चला गया।

कटौती के तहत समस्या का समाधान।

फिर भी यह काम किया, क्या गलत हुआ?

हमें पूर्ण त्रुटि ट्रेस मिलता है:

हम देखते हैं कि asm ClassVisitor लाइब्रेरी के निर्माण में त्रुटि लाइन 79 पर है। आइए वहां देखें, लेकिन ClassVisitor को खोलने की कोशिश करते समय, स्टूडियो ने 2 विकल्प पेश किए

मेरा प्लगइन asm संस्करण 7.2 का उपयोग करता है, इसलिए हम वहां जाते हैं और लाइन 79 पर हम निम्नलिखित देखते हैं:

यह स्पष्ट रूप से नहीं है कि हमें क्या चाहिए। अब ClassVisitor संस्करण 6 पर जाएं:

एक संदेश के बिना बस हमारे IllegalArgumentException । मेरा प्लगइन Opcodes.ASM7 के ASM एपीआई 7 संस्करण का उपयोग करता है, और पुस्तकालय के 6 संस्करण में यह एपीआई अभी तक मौजूद नहीं है, इसलिए, एक Opcodes.ASM7 में Opcodes.ASM7 करता है। हम यह निष्कर्ष निकाल सकते हैं कि प्लगइन को लाइब्रेरी का गलत संस्करण प्राप्त है।

कचरा सवाल, मैंने सोचा, और यह किया:

 configurations.all { resolutionStrategy { force "org.ow2.asm:asm:7.2" } } 

मेरे अफसोस के लिए, यह बिल्कुल कोई प्रभाव नहीं था। मुझे अभी भी सटीक कारण पता नहीं चल पाया है कि asm संस्करण को ओवरफ़िक्स करना क्यों संभव नहीं है, हालाँकि ./gradlew app:dependencies कमांड से पता चलता है कि संस्करण को 7.2 के साथ बदल दिया गया है। यदि किसी के विचार या धारणाएं हैं, तो मुझे एक राय सुनकर खुशी होगी।

समस्या को किसी तरह हल किया जाना चाहिए

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

 apply plugin: 'org.anarres.jarjar' ... dependencies { implementation fileTree(dir: 'build/jarjar', include: ['*.jar']) implementation jarjar.repackage('asm') { from 'org.ow2.asm:asm:7.2' classRename "org.objectweb.asm.**", "stater.org.objectweb.asm.@1" } } 

इस मामले में build/jarjar , वह निर्देशिका जिसमें build/jarjar लाइब्रेरी जार फाइल को रीपैकेजेड पैकेज के साथ जनरेट किया जाएगा, इसलिए आपको fileTree माध्यम से इस निर्देशिका तक निर्भरता खोलने की आवश्यकता है। पुस्तकालय अब आयात stater.org.objectweb.asm.* साथ उपलब्ध होगा stater.org.objectweb.asm.* इसके बजाय org.objectweb.asm.* । इस प्लगइन में विभिन्न सेटिंग्स हैं, लेकिन मेरे उदाहरण में, बस पैकेज बदलना काफी था।

इसके बाद, पूरे प्रोजेक्ट पर जाएं और org.objectweb.asm से हर जगह आयात बदलें
stater.org.objectweb.asm । मेरी राय में, एक बहुत ही सुविधाजनक उपयोगिता, इसे हाथ से करने से कई बार आसान है, खासकर पुस्तकालय को अपडेट करते समय, हम बस from 'org.ow2.asm:asm:7.2' से नए संस्करण में बदलते हैं और नए संस्करण के साथ from 'org.ow2.asm:asm:7.2' जार उपनाम उत्पन्न होगा। स्वचालित मशीन।

यदि आपके पास बस एक परियोजना है (पुस्तकालय नहीं), तो यह आपके लिए अघुलनशील संघर्षों को हल करने के लिए पर्याप्त होगा, जैसे कि लेख की शुरुआत में उल्लिखित गन्स। लेकिन अगर आप, मेरी तरह, एक पुस्तकालय लिखते हैं, तो वह सब नहीं है।

हमने रीपैकेजिंग समस्या को हल कर दिया है, लेकिन अब asm रिमोट मावेन रिपॉजिटरी पर निर्भरता के माध्यम से नहीं बल्कि स्थानीय जार फ़ाइल के माध्यम से प्रोजेक्ट asm जुड़ा है, जो कि बस तब खो जाएगा जब आपकी लाइब्रेरी परिनियोजित होगी और इस तरह की एक NoClassDefFoundError त्रुटि होगी। लेकिन यह समस्या हल करने के लिए काफी सरल है:

1. हमारी श्रेणी फ़ाइल में, एक नया कॉन्फ़िगरेशन बनाएँ:

   
   

    configurations { extraLibs implementation.extendsFrom(extraLibs) } 

   
   

2. आगे हम बदलते हैं

   
   

    implementation fileTree(dir: 'build/jarjar', include: ['*.jar']) 

   
   

   पर

   
   

    extraLibs fileTree(dir: 'build/jarjar', include: ['*.jar']) 

   
   

3. उस कार्य को फिर से परिभाषित करें जो आपकी अंतिम जार फ़ाइल को इकट्ठा करने के लिए जिम्मेदार है और अंतिम जार में हमारे नए कॉन्फ़िगरेशन के साथ सभी पुस्तकालयों को लिखें:

   
   

    jar { from { configurations.extraLibs.collect { it.isDirectory() ? it : zipTree(it) } } } 

   
   

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

और अगर आप सिर्फ परस्पर विरोधी लाइब्रेरी की जार फ़ाइल को बिना रीपैकेजिंग के प्लगइन से कनेक्ट करते हैं?

बुरा विचार, इससे कुछ भी अच्छा नहीं होगा। परियोजना के निर्माण की प्रक्रिया में, इस तरह के एक दिलचस्प कार्य की check...DuplicateClasses , जो बस एक ही पैकेज के साथ फाइलों को काट देता है। यही है, कनेक्टेड लाइब्रेरी की जार फाइल से प्राप्त फाइलें और रिमोट रिपॉजिटरी के माध्यम से उसी लाइब्रेरी से फाइल। परिणाम यह त्रुटि होगी:

वह सब है। पढ़ने वाले सभी को धन्यवाद!

पुन: निर्माण के लिए तुलसा
उदाहरण प्लगइन