गो परियोजनाओं के निर्माण के लिए मावेन-वे

पहला, थोड़ा बैकग्राउंड। 2010 की शुरुआत में, मैंने BK-0010 एमुलेटर की BIN फ़ाइलों के लिए WAV फ़ाइलों के लिए एक छोटी कनवर्टर उपयोगिता बनाई। उपयोगिता को अधिकतम पोर्टेबिलिटी के लक्ष्य के साथ पायथन में लिखा गया था, इसने समस्याओं के बिना काम किया और मैं इसके बारे में थोड़ी देर के लिए भूल गया। लेकिन 2016 में, उपयोगकर्ता दिखाई दिया, जिसे पायथन के बारे में कोई पता नहीं था और इसे कैसे स्थापित किया जाए। वह एक सरल निष्पादन योग्य मोनोलिथ चाहता था जो "बस काम करेगा।" उनका अनुरोध मुझे तर्कसंगत लगा, और मैंने मुख्य प्लेटफार्मों के लिए बाइनरी निष्पादन योग्य फ़ाइलों के एक सेट के रूप में उपयोगिता को फिर से बनाने का फैसला किया।

पायथन और जावा ने ऐसा अवसर नहीं दिया (जब तक कि कई दसियों मेगाबाइट द्वारा उपयोगिता को बढ़ाने की इच्छा नहीं थी)। संभावित रूप से, समाधान C / C ++ में किया जा सकता है, लेकिन प्लेटफार्मों के ऐसे लक्षित कवरेज के साथ, क्रॉस-संकलन के साथ कठिनाइयां कार्य के लिए आवंटित समय से परे हो जाएंगी (और मुझे 64 और 32 बिट में विंडोज, लिनक्स और मैकओएस के लिए क्रॉस-असेंबली का समर्थन करना पड़ा था embodiments)। इसलिए मैंने भाषा पर ध्यान आकर्षित किया, जो कि लोकप्रियता प्राप्त कर रही है, जो उस समय तक पहले से ही काफी परिपक्व हो गई थी और एक ही व्यक्ति जो बिना किसी तंबू के साथ सभी नृत्य करता है, उसे बॉक्स से बाहर सभी आवश्यक क्रॉस-संकलन प्रदान करता है!) ।

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

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

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

• चरण क्लीन में default-clean क्लीन के रूप में साफ
• default-fix चरण के रूप में default-fix
• प्रारंभिक चरण में default-get
• जनरेट -सोर्स चरण में default-generate
• प्रक्रिया-स्रोत चरण में default-fmt एफएमटी के रूप में default-fmt
• परीक्षण चरण में default-test परीक्षण के रूप में परीक्षण
• पैकेज चरण में default-build बिल्ड के रूप में default-build
• default-install रूप में default-install mvninstall आंतरिक कार्य को इंस्टॉल चरण में निष्पादित किया जाता है
• default-deploy रूप में स्थापित default-deploy स्थापित चरण में

किसी भी मूल चरण को कार्य को किसी भी चरण में अनुवाद करके अक्षम किया जा सकता है:

 <execution> <id>default-fix</id> <phase>none</phase> </execution> 

आंतरिक कार्यान्वयन में, कार्यों को "निर्भरता के साथ काम करना" और "निर्भरता के समाधान की आवश्यकता नहीं" में विभाजित किया गया था, मॉड्यूल मोड के लिए समर्थन की उपस्थिति के बाद, अधिकांश "निर्भरता के साथ काम" करने के लिए चले गए।

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

 <build> ```${basedir}/src</sourceDirectory> <directory>${basedir}/bin</directory> <plugins> <plugin> <groupId>com.igormaznitsa</groupId> <artifactId>mvn-golang-wrapper</artifactId> <version>2.3.3</version> <extensions>true</extensions> <configuration> <goVersion>1.12.9</goVersion> </configuration> </plugin> </plugins> </build> 

चेतावनी! किसी कारण से, HabR XML को फॉर्मेट करते समय गलत तरीके से <sourceDirectory>${basedir}/src</sourceDirectory> सेक्शन प्रदर्शित कर सकता है।

जैसा कि आप देख सकते हैं, आपको सीधे स्रोत फ़ोल्डर /src और फ़ोल्डर को परिणाम /bin साथ निर्धारित करना होगा। एक तरफ, यह एक शून्य है, दूसरी तरफ, उनके स्थान को बदलने की संभावना है।

एक एकल-मॉड्यूल परियोजना, एक ला हैलो दुनिया के लिए संपूर्ण न्यूनतर pom.xml इस प्रकार है:

 <?xml version="1.0" encoding="UTF-8"?> <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.igormaznitsa</groupId> <artifactId>mvn-golang-helloworld</artifactId> <version>1.0.0-SNAPSHOT</version> <packaging>mvn-golang</packaging> <build> ```${basedir}/src</sourceDirectory> <directory>${basedir}/bin</directory> <plugins> <plugin> <groupId>com.igormaznitsa</groupId> <artifactId>mvn-golang-wrapper</artifactId> <version>2.3.3</version> <extensions>true</extensions> <configuration> <goVersion>1.12.9</goVersion> </configuration> </plugin> </plugins> </build> </project> 

कृपया ध्यान दें कि प्रोजेक्ट पैकेजिंग को mvan-golang के रूप में नामित किया गया है। यह कॉन्फ़िगरेशन निष्पादन योग्य फ़ाइल बनाने और इसे src फ़ोल्डर में स्रोत ग्रंथों के आधार पर परिणामी बिन फ़ोल्डर में डालने के लिए पर्याप्त है। गो बिल्ड कैश भी /bin (डिफ़ॉल्ट रूप से /bin /bin/.goBuildCache रूप में) में बनाया जाएगा और इस अस्थायी फ़ोल्डर के साथ साफ मिटा दिया जाएगा।

स्थापित चरण में, आंतरिक mvninstall टास्क को mvninstall , जो पूरी परियोजना को एक ज़िप आर्काइव में पैक करता है और इसे मावेन रिपॉजिटरी में एक उत्पन्न कलाकृति के रूप में रखता है। प्रारंभ में, मैंने सिर्फ इन कलाकृतियों को संग्रहीत किया, लेकिन संस्करण 2.3.2 से एक तंत्र को मानक मावेन निर्भरता के रूप में समर्थन करने के लिए जोड़ा गया और मावेन रिपॉजिटरी के माध्यम से "साझा" कॉमन कोड के साथ परियोजनाओं को विकसित करना संभव हो गया। यह स्पष्ट है कि उत्पन्न द्विआधारी परिणामों को रिपॉजिटरी में रखना कलाकृतियों के रूप में क्रॉस-प्लेटफॉर्म आवश्यकताओं के कारण एक बुरा विचार है और इसलिए /bin फ़ोल्डर की सामग्री को कलाकृतियों में पैक नहीं किया जाता है।

mvn-golang निर्भरता के रूप में पैकेजिंग mvn-golang साथ एक और परियोजना को mvn-golang कुछ इस तरह है:

 <dependency> <groupId>com.igormaznitsa</groupId> <artifactId>mvn-go-test-mix-terminal</artifactId> <version>1.0.0-SNAPSHOT</version> <type>mvn-golang</type> </dependency> 

संस्करण 2.3.3 के साथ, मॉड्यूल के गो तंत्र के साथ काम करने के लिए समर्थन जोड़ा गया था, लेकिन डिफ़ॉल्ट रूप से यह सक्रिय नहीं है (पिछड़े संगतता के लिए) और कॉन्फ़िगरेशन पैरामीटर का उपयोग करने में सक्षम है:

 <moduleMode>true</moduleMode> 

जब गो-मॉड्यूल का तंत्र प्रयोगात्मक चरण में था, तो मैंने सीवीएस उपयोगिताओं के लिए सीधे कॉल के माध्यम से निर्भरता संस्करणों के साथ काम करने के लिए समर्थन जोड़ा, एक परीक्षण उदाहरण बनाया गया था । लेकिन अब मुझे लगता है कि इस तरह के तंत्र में कोई बड़ी दिलचस्पी नहीं है और यह मॉड्यूल के माध्यम से मानक निर्भरता का उपयोग करने के लिए अधिक लाभदायक है। इसके अलावा, प्लगइन परियोजना के निर्माण के समय में go.mod फ़ाइलों को प्रीप्रोसेस करने में सक्षम है, अगर मल्टी-मॉड्यूल प्रोजेक्ट के ढांचे के भीतर काम चल रहा है, तो स्थानीय फ़ोल्डरों के लिए रास्तों को बदल दें।

चूंकि मावेन ने कट्टरपंथियों का उपयोग करके मानकीकरण की संभावना प्रदान की है, इसलिए मैंने दो चापलूसी की:

• com.igormaznitsa: mvan-golang-hello: 2.3.3 एक साधारण एकल-मॉड्यूल आर्कटाइप के लिए
• com.igormaznitsa: mvan-golang-hello-multi: साझा स्रोत कोड वाली बहु-मॉड्यूल परियोजना के लिए 2.3.3

एकल-मॉड्यूल प्रोजेक्ट के श्लोक के साथ काम करने का एक उदाहरण नीचे दिए गए एनीमेशन में देखा जा सकता है
।

तुम भी बस "हैलो वर्ल्ड" परियोजना को क्लोन कर सकते हैं और चारों ओर खेल सकते हैं:

 git clone https://github.com/raydac/mvn-golang-example.git 

अक्सर एक उचित प्रश्न उठता है - यह सब क्यों आवश्यक है और मावेन का उपयोग गो-प्रोजेक्ट के निर्माण की प्रक्रिया में क्या बोनस देता है? मैं इसका जवाब बिंदु से देने की कोशिश करूंगा:

1. मावेन एक बहुत ही परिपक्व, क्रॉस-प्लेटफ़ॉर्म प्रोजेक्ट-बिल्डिंग वातावरण है, जो लगभग सभी CI प्लेटफार्मों द्वारा समर्थित है, उदाहरण के लिए जेनकिंस, गो 2 एक्सयूनाइट का उपयोग करके आप परीक्षण के परिणामों को प्लगइन्स को रिपोर्ट करके प्रदर्शित प्रारूप में बदल सकते हैं।
2. मावेन क्रॉस-प्लेटफ़ॉर्म है और सभी ऑपरेटिंग सिस्टम द्वारा समर्थित है, सभी रिपॉजिटरी में शामिल किया जा रहा है। लचीले रूप से सक्रिय प्रोफाइल की उपस्थिति विभिन्न प्लेटफार्मों के लिए प्रक्रिया को अनुकूलित करना आसान बनाती है।
3. मावेन में प्लगइन्स की एक बड़ी मात्रा है , जो गो और GWT के संयोजन से परियोजना के लिए ANTLR को जोड़ते हुए, प्रोटोबॉफ़ विवरणकों के आधार पर गो को उत्पन्न करने और यहां तक कि प्रीवाइसिंग को जोड़कर एक सहक्रियात्मक प्रभाव प्राप्त करना आसान बनाता है। यह सब मैन्युअल रूप से बैच फ़ाइलों के माध्यम से आयोजित किया जा सकता है, लेकिन अगर आधिकारिक समर्थित प्लगइन्स हैं, तो उनका उपयोग करना अधिक लाभदायक है।
4. यह परियोजना मशीनों और प्लेटफार्मों के बीच आसानी से पोर्टेबल हो जाती है, और GoSDK संस्करण को स्विच करना एक पंक्ति को बदलकर किया जाता है।
5. मावेन रिपॉजिटरी के माध्यम से सोर्स कोड के पृथक्करण के साथ मल्टी-मॉड्यूल प्रोजेक्ट्स को व्यवस्थित करने में आसानी।
6. उपकरण जावा डेवलपर्स से परिचित और परिचित है, जो गोलंग पर विकास पर स्विच करते समय या बहुभाषी गो / जावा समाधान विकसित करते समय उनके अनुकूलन की सुविधा प्रदान करता है।
7. गो में वातावरण में छद्म विकास की संभावना है जो मावेन का समर्थन करते हैं, भले ही उनके पास इस मंच के लिए कोई समर्थन न हो, उदाहरण के लिए, नेटबीन्स आईडीई में ।

समाधान की सबसे बड़ी कमी, मेरी राय में, यहाँ एक है - गोलंग समुदाय के बीच मावेन से परिचित डेवलपर्स की एक सीमित संख्या। सी / सी ++ के साथ गोलंग में जाने वालों के लिए, यह स्पष्ट है कि बनाने के लिए कुछ करीब और प्रिय को ढूंढना मुश्किल है, साथ ही साथ किसी ने "देशी" गो-बिल्ड सिस्टम को रद्द नहीं किया है। मैंने देखा कि किसी कारण से, कई डेवलपर्स प्लेटफार्मों को मिश्रण करना पसंद नहीं करते हैं।

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

प्लगइन परियोजना में परीक्षण उदाहरण देव संस्करण का उपयोग करते हैं, इसलिए यदि आप परियोजना को क्लोन करने के बाद उन्हें स्थानीय रूप से बनाना चाहते हैं, तो आपको पहले परियोजना रूट निर्देशिका में कमांड का उपयोग करके प्लगइन के देव संस्करण का निर्माण करना होगा:

 mvn install 

जिसके बाद, आप किसी भी mvn-golang-examples में जा सकते हैं और इसके साथ निर्माण कर सकते हैं

 mvn clean install 

आप परियोजना के मूल से सभी उदाहरणों का निर्माण शुरू कर सकते हैं, का उपयोग कर

 mvn clean install -Pexamples 

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

 mvn clean install -Pexamples -T6 

विकास के दौरान, परियोजना ने "घंटियाँ और सीटी" की एक सभ्य राशि जमा की है, जिसे मैंने इस छोटे लेख में शामिल नहीं करने का फैसला किया है। छोटे विन्यास उदाहरणों के मापदंडों के बारे में जानकारी इस प्लगइन के माइंड मैप में देखी जा सकती है ( SciaReto फॉर्मेट में सोर्स फाइल यहाँ है ):