🌞 ⛅️ ⛰️ मावेन के साथ दूसरा जीवन 👈🏿 🔨 🚺

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

लेकिन कुछ बिंदु पर अंतराल इतना महत्वपूर्ण हो जाता है कि उत्पाद प्रतिस्पर्धी होना बंद हो जाता है और धीरे-धीरे बाजार से गायब हो जाता है। यह क्रमिक क्षीणन की ऐसी स्थिति थी जिसका मैं निरीक्षण करने के लिए हुआ था।

यहां मैं इस बारे में बात करना चाहता हूं कि कैसे एक विशेष मामले में मैंने अपरिहार्य को विलंब करने की कोशिश की और इस पर मावेन परियोजना कलेक्टर का उपयोग करके विकास को फिर से जीवित किया।

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

इसलिए दिया गया:

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

इस प्रकार, मुख्य विकास ऊपर वर्णित ~~जादू~~ लागू भाषा में किया जाता है, जिनमें से सभी आकर्षण, शायद, सम्मानित समुदाय को भयभीत कर सकते हैं, और "कोर" समय-समय पर (हर महीने में एक-दो बार नया संस्करण) प्रधान कार्यालय से दिया जाता है और संशोधित नहीं किया जा सकता है।

यह बहुत संभावना है कि पास्कल के समान अपनी खुद की प्रोग्रामिंग भाषा को विकसित करना और बनाए रखना और डेल्फी के आधार पर बनाया गया था, शायद एक बुरा विचार था, लेकिन 15-17 साल पहले, जब यह सब शुरू हुआ, तो किसी ने इसके बारे में नहीं सोचा था। अन्य लक्ष्यों का पीछा किया गया था, जो सामान्य तौर पर, सफलतापूर्वक हासिल किए गए थे।

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

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

स्थिति को मापने के लिए, साझा कोड पुस्तकालयों ( पैकेज ) के एक सेट का उपयोग करके एक रिपॉजिटरी (रिपॉजिटरी) और एक परियोजना संग्रह प्रणाली को व्यवस्थित करने का निर्णय लिया गया था।

मावेन को इसके लिए एक उपकरण के रूप में चुना गया था, क्योंकि डिफ़ॉल्ट रूप से यह समान कार्य करता है, एक लचीला जीवन चक्र और प्लग-इन सिस्टम का विशाल लचीलापन होता है।

लेकिन पहले बातें पहले

मुख्य समस्या, जिसे मुझे अपने शोध की शुरुआत में भी संदेह नहीं था, यह था कि पैकेजों में वे फाइलें होनी चाहिए जो बाइट कोड में संकलित न हों, जैसा कि स्रोत, जैसा कि संकलन "कर्नेल" के उस संस्करण के ठीक नीचे होना चाहिए जिसके लिए उनका उपयोग किया जाएगा। सादगी के लिए, हम अपने एप्लिकेशन स्रोत को bpas कहते हैं। यह मावेन में मानक नियंत्रण रेखा से थोड़ा विपरीत है।

इस तरह के खुलासे के बाद, सूत्रों से एक पैकेज बनाने का फैसला किया गया था, लेकिन गठन के दौरान उनके परमाणु संकलन की जांच करना आवश्यक है। दूसरे शब्दों में, .class को पहली बार संकलित करते समय लगभग मानक मावेन जीवन चक्र का उपयोग करें, और फिर संसाधनों के साथ मिलकर इसे जार में पैक किया जाता है। केवल मेरे मामले में, संकलित फ़ाइलों के बजाय, पैकेज ज़िपित स्रोत bpas से बनाया गया था।

मावेन कैसे काम करता है, इसके बारे में थोड़ा सा

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

और एलसी के कुछ चरण को शुरू करने की कोशिश करते हुए, उदाहरण के लिए, "एमवीएन संकलन", मैं वास्तव में कंप्लीट करने के लिए (प्रोजेक्ट सत्यापन) से पूरे चरण की श्रृंखला को चलाता हूं, बिना किसी एक को याद किए। कुछ चरणों के लिए, तथाकथित डिफ़ॉल्ट प्लगइन्स हैं जिन्हें इस तथ्य के बावजूद कहा जाएगा कि pom.xml (मेवेन प्रोजेक्ट की मुख्य फ़ाइल) में केवल हेडर है और प्लगइन्स के लॉन्च का एक भी संकेत नहीं है।

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

यहाँ इस तरह के एक बिल्कुल वैध खाली pom.xml है, अपनी खालीपन के बावजूद, mvan परिनियोजित कमांड प्राप्त होने पर, यह src / main फ़ोल्डर से प्रारंभिककरण, संकलन, पैकेजिंग और जावा प्लग-इन को लॉन्च करेगा।

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.projectgroup</groupId> <artifactId>projectname</artifactId> <version>01.03.03-00</version> <build> </build> </project>

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

Pom.xml में एक नया जीवनचक्र का निर्माण

पैकेजों को लागू करने के लिए, निम्नलिखित जीवन चक्र चुना गया था।

initialize (इनिशियलाइज़ेशन) - कॉन्फ़िगरेशन (प्रॉपर्टी या की = वैल्यू) फ़ाइल से सेटिंग पढ़ें और उन्हें प्रॉपर्टीज टैग में जोड़ें। हम थोड़ी देर बाद गुणों के टैग के बारे में बात करेंगे।
जेनरेट-सोर्स (सोर्स कोड जेनरेशन) - जिप से उन सभी पैकेजों को डाउनलोड और अनपैक करें जो वर्तमान पैकेज / प्रोजेक्ट के स्रोतों के साथ-साथ आगे के संकलन के लिए एक अलग निर्देशिका में इस पैकेज / प्रोजेक्ट की निर्भरताएं हैं।
संकलन - हमारे bpas के लिए हमारा संकलन प्लगइन चलाएं, जो सही संकलन क्रम को निर्धारित करता है और हमारी भाषा के लिए कमांड लाइन कंपाइलर शुरू करता है। मैं नीचे अपने स्वयं के प्लगइन के बारे में संक्षेप में बात करूंगा, लेकिन मेरा सुझाव है कि इस लेख के दायरे के बाहर इसे लिखने के लिए मार्गदर्शिका को स्थानांतरित करें।
असेंबली - हम स्रोत फ़ाइलों की उपनिर्देशिकाओं की संरचना को संरक्षित करते हुए पैकेज को bipas स्रोतों से ज़िप में पैक करते हैं।
तैनात (हमारे मामले में, रिपॉजिटरी के लिए उतराई) - असेंबली चरण में एकत्रित विधानसभा ज़िप को स्थानीय मावेन रिपॉजिटरी को pom.xml और अन्य पैकेज जानकारी के साथ भेजा जाता है। यह प्रक्रिया सामान्य तैनात जार फ़ाइल के लिए लगभग समान है, लेकिन विशेष मापदंडों के साथ।

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

Pom.xml की सामान्य संरचना

मैं सशर्त रूप से pom.xml को दो भागों में विभाजित करता हूं: हेडर और असेंबली।

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

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

बिल्ड टैग में जीवनचक्र कार्यान्वयन

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

इनिशियलाइज़

यहाँ फिर से, थोड़ा और अलग से गुण टैग का उल्लेख करते हैं। आइए हम बताते हैं कि इसकी आवश्यकता क्यों है और इसका उपयोग कैसे किया जाता है।

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

सबसे कम प्राथमिकता गुण टैग के लिए सीधे गुणों को लिखना है, उदाहरण के लिए इस तरह:

  <properties> <helloText>Hello my friend</ helloText > </properties>

मावेन शुरू होने पर प्रत्यक्ष प्राथमिकता को एक उच्च प्राथमिकता दी जाती है, जैसे कि "mvan –DhelloText = Hi initialize"
जब मावेन इस पैरामीटर के साथ शुरू होता है, तो हेल्लोटेक् ट टैग के प्रारंभिक मूल्य को वर्तमान सत्र के लिए लॉन्च लाइन में पारित मूल्य से बदल दिया जाएगा, अर्थात। xml में इसे सेव नहीं किया जाएगा। यदि ऐसा कोई निरंतर अस्तित्व में नहीं था, तो इस सत्र के लिए यह मौजूद होगा और इसका उपयोग किया जा सकता है। सभी गैर-मौजूद स्थिरांक का मान एक रिक्त स्ट्रिंग है।

वर्तमान सत्र में प्लगइन्स द्वारा प्रॉपर्टीज़ टैग में मूल्यों को जोड़ने के लिए सर्वोच्च प्राथमिकता दी गई है। वे pom.xml में भी सहेजे नहीं गए हैं। यह इस प्रणाली है कि हम "नाम = मान" वाले गुण फ़ाइल में अलग-अलग असेंबली सेटिंग्स बनाने के लिए उपयोग करेंगे
ऐसा करने के लिए, गुण-मावेन-प्लगइन प्लगइन का उपयोग करें

  <build> … <plugins> … <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>properties-maven-plugin</artifactId> <version>1.0-alpha-1</version> <executions> <execution> <id>1</id> <phase>initialize</phase> <goals> <goal>read-project-properties</goal> </goals> <configuration> <files> <file>..\build.conf</file> </files> </configuration> </execution> <execution> <id>2</id> <phase>pre-clean</phase> <goals> <goal>read-project-properties</goal> </goals> <configuration> <files> <file>..\build.conf</file> </files> </configuration> </execution> </executions> </plugin> … </plugins>

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

उत्पन्न-स्रोतों

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

  <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-assembly-plugin</artifactId> <version>2.2.1</version> <executions> <execution> <id>unpackSources</id> <phase>generate-sources</phase> <goals> <goal>unpack</goal> </goals> </execution> </executions> <configuration> <workDirectory>${packagesPath}</workDirectory> </configuration> </plugin>

$ {PackagePath} के निर्माण का अर्थ है कि आपको टैग “/ प्रोजेक्ट / प्रॉपर्टीज / packagePath” से मूल्य लेने की आवश्यकता है।

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

संकलन

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

  <plugin> <groupId>com.companyname.utils</groupId> <artifactId>BPASCompilerPlugin</artifactId> <version>0.1.0.2</version> <executions> <execution> <phase>compile</phase> <goals> <goal>bpascompile</goal> </goals> </execution> </executions> <configuration> <protectionServer>${protectionServerName}</protectionServer> <protectionAlias>${protectionServerAlias}</protectionAlias> <bpasccPath>${pathToBPASCC}</bpasccPath> <binaryVersion>${env.BINARY_VERSION}</binaryVersion> </configuration> </plugin>

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

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

सभा

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

  <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-assembly-plugin</artifactId> <version>2.2.1</version> <executions> <execution> <id>unpackSources</id> <phase>generate-sources</phase> <goals> <goal>unpack</goal> </goals> </execution> <execution> <id>packSources</id> <phase>assembly</phase> <goals> <goal>assembly</goal> </goals> </execution> </executions> <configuration> <descriptors> <descriptor>..\src.xml</descriptor> </descriptors> <workDirectory>${packagesPath}</workDirectory> </configuration> </plugin>

यहां हम आईडी = पैक्स स्रोत और इस चरण के लिए आवश्यक सेटिंग्स .. \ src.xml के साथ दूसरा निष्पादन अनुभाग देखते हैं। Srxxml में स्रोतों को पैकेज करने के लिए सेटिंग्स शामिल हैं। वास्तव में, इन सभी सेटिंग्स को सीधे डिस्क्रिप्टर टैग में रखा जा सकता है, लेकिन यह pom.xml के साथ बहुत क्लॉट किया जा सकता है।
चित्र को पूरा करने के लिए यहाँ src.xml का एक उदाहरण दिया गया है।

 <?xml version="1.0" encoding="UTF-8"?> <!-- standart pack settings for bpas package--> <assembly> <id>src</id> <formats> <format>zip</format> </formats> <fileSets> <fileSet> <includes> <include>pom.xml</include> </includes> </fileSet> <fileSet> <directory>SOURCE</directory> <excludes> <exclude>.svn</exclude> <exclude>**/*${packagesDirName}*/**</exclude> </excludes> </fileSet> </fileSets> </assembly>

packageDirName / project / properties pom.xml फ़ाइल से एक स्थिर है
अलग से, मैं यह नोट करना चाहता हूं कि एक अलग फ़ाइल में पैकेज सेटिंग्स के इस तरह के हस्तांतरण ने मुझे सभी पैकेजों के लिए एक पैकेज कॉन्फिगरेशन बनाने की अनुमति दी, जो बेहद सुविधाजनक है।

तैनाती

तैनाती चरण भी मावेन द्वारा लॉन्च किया गया है, भले ही हमने इस प्लगइन के लिए सेटिंग्स निर्दिष्ट की हों या नहीं। उन्हें फिर से परिभाषित करके, हमने इस प्लगइन को अपने लिए काम किया।

  <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-deploy-plugin</artifactId> <version>2.5</version> <configuration> <file>${project.build.directory}\${project.artifactId}-src.zip</file> <url>${project.distributionManagement.repository.url}</url> <repositoryId>${project.distributionManagement.repository.id}</repositoryId> <groupId>${project.groupId}</groupId> <artifactId>${project.artifactId}</artifactId> <version>${project.version}</version> <packaging>zip</packaging> <pomFile>pom.xml</pomFile> </configuration> </plugin>

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

स्वच्छ

जैसा कि मैंने कहा, स्वच्छ चरण, मानक LC का हिस्सा नहीं है। इसका प्रारंभिक कार्य यह है कि mvan क्लीन कमांड निष्पादित होने के बाद, परियोजना में महत्वपूर्ण गतिविधि का कोई निशान नहीं रहता है। हमारे मामले में, मानक targetSource फ़ोल्डर (बिल्ड टैग में इंगित) के अलावा, आपको उन सभी पैकेजों को भी हटाना होगा जो पैकेज / प्रोजेक्ट के सफल संकलन के लिए निर्भरता के रूप में "मर्ज किए गए" थे।

तो, सेटिंग्स:

  <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-clean-plugin</artifactId> <version>2.4.1</version> <configuration> <filesets> <fileset> <directory>${packagesPath}</directory> </fileset> </filesets> </configuration> </plugin>

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

यह ध्यान में रखते हुए कि पहली बार में व्यक्तिगत सेटिंग्स शाखाओं से निपटना कितना मुश्किल है, मैं नीचे दिए गए पैकेजों में से एक का पूरा पाठ pom.xml दे दूंगा।

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.companyname.packages</groupId> <artifactId>String</artifactId> <version>0.1.0.1</version> <name>String</name> <url>http://maven.apache.org</url> <properties> <project.build.sourceEncoding>windows-1251</project.build.sourceEncoding> <packagesPath>${basedir}/SOURCE/${packagesDirName}</packagesPath> </properties> <distributionManagement> <repository> <id>spb-maven-repo</id> <name>spb-maven-repo</name> <url>file://\\SPB-FS\maven-repo</url> </repository> </distributionManagement> <pluginRepositories> <pluginRepository> <id>spb-maven-repo</id> <name>spb-maven-repo</name> <releases> <enabled>true</enabled> <updatePolicy>always</updatePolicy> <checksumPolicy>fail</checksumPolicy> </releases> <snapshots> <enabled>true</enabled> <updatePolicy>always</updatePolicy> <checksumPolicy>fail</checksumPolicy> </snapshots> <url>http://spb-maven-repo</url> <layout>default</layout> </pluginRepository> </pluginRepositories> <repositories> <repository> <id>spb-maven-repo</id> <url>http://spb-maven-repo</url> </repository> </repositories> <dependencies> <dependency> <groupId>com.companyname.packages</groupId> <artifactId>Arithm</artifactId> <version>0.1.0.1</version> <type>zip</type> </dependency> <dependency> <groupId>com.companyname.packages</groupId> <artifactId>bUnit</artifactId> <version>0.9.0.0</version> <type>zip</type> </dependency> </dependencies> <build> <directory>USER</directory> <sourceDirectory>${basedir}/SOURCE</sourceDirectory> <finalName>${project.artifactId}</finalName> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>properties-maven-plugin</artifactId> <version>1.0-alpha-1</version> <executions> <execution> <id>1</id> <phase>initialize</phase> <goals> <goal>read-project-properties</goal> </goals> <configuration> <files> <file>..\build.conf</file> </files> </configuration> </execution> <execution> <id>2</id> <phase>pre-clean</phase> <goals> <goal>read-project-properties</goal> </goals> <configuration> <files> <file>..\build.conf</file> </files> </configuration> </execution> </executions> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-assembly-plugin</artifactId> <version>2.2.1</version> <executions> <execution> <id>unpackSources</id> <phase>generate-sources</phase> <goals> <goal>unpack</goal> </goals> </execution> <execution> <id>packSources</id> <phase>assembly</phase> <goals> <goal>assembly</goal> </goals> </execution> </executions> <configuration> <descriptors> <descriptor>..\src.xml</descriptor> </descriptors> <workDirectory>${packagesPath}</workDirectory> </configuration> </plugin> <plugin> <groupId>com.companyname.utils</groupId> <artifactId>CompilerPlugin</artifactId> <version>0.1.0.2</version> <executions> <execution> <phase>compile</phase> <goals> <goal>compile</goal> </goals> </execution> </executions> <configuration> <protectionServer>${protectionServerName}</protectionServer> <protectionAlias>${protectionServerAlias}</protectionAlias> <bpasccPath>${pathToBPASCC}</bpasccPath> <binaryVersion>${env.BINARY_VERSION</binaryVersion> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-deploy-plugin</artifactId> <version>2.5</version> <configuration> <file>${project.build.directory}\${project.artifactId}-src.zip</file> <url>${project.distributionManagement.repository.url}</url> <repositoryId>${project.distributionManagement.repository.id}</repositoryId> <groupId>${project.groupId}</groupId> <artifactId>${project.artifactId}</artifactId> <version>${project.version}</version> <packaging>zip</packaging> <pomFile>pom.xml</pomFile> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-clean-plugin</artifactId> <version>2.4.1</version> <configuration> <filesets> <fileset> <directory>${packagesPath}</directory> </fileset> </filesets> </configuration> </plugin> </plugins> </build> </project>

परिणाम

मैंने हर चीज को यथासंभव विस्तृत रूप से समझाने की कोशिश की, लेकिन सभी एक जैसे, पर्दे के पीछे अभी भी बड़ी संख्या में प्रश्न थे जिन्हें मैं बाद के लेखों में शामिल करने की योजना बना रहा हूं।

चरण और लक्ष्य उनके और प्लगइन्स के बीच का रिश्ता है।
archetypes बनाना - अपने pom.xml कॉन्फ़िगरेशन और डिफ़ॉल्ट फ़ाइलों का एक सेट जल्दी से तैनात करने के लिए एक प्रोजेक्ट टेम्पलेट।
मावेन रिपॉजिटरी और उनका प्रबंधन।
कैसे लिखें और अपने Maven प्लगइन को डिबग करें।
कैसे हर "छींक" के लिए अपना खुद का प्लगइन लिखने के लिए नहीं।

इस तथ्य के बावजूद कि मैं स्वयं अपने काम से प्रसन्न था, मैं यह स्वीकार करने के लिए तैयार हूं कि इस रूप में परियोजना को इकट्ठा करने वाले बैच के लिए प्रणाली अभी भी एकदम सही है, हालांकि, उपरोक्त विवरण बैच / परियोजना के पूर्ण जीवन चक्र के कार्यान्वयन को पर्याप्त रूप से दिखाता है। वास्तव में, यह एक व्यावहारिक रूपरेखा है, जिसके शीर्ष पर आप लगभग संभावनाओं का विस्तार कर सकते हैं।

ऐसे बैच असेंबली के मुख्य लाभ हैं:

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

उपयोगी लिंक

संस्करण निर्भरता का इस्तेमाल किया
मावेन और उन पर प्रलेखन के लिए प्लगइन्स का सबसे बुनियादी सेट
मुख्य मावेन भंडार में शामिल प्लगइन्स का एक अतिरिक्त सेट

मावेन के साथ दूसरा जीवन