ग्रेड और ऑटोमेशन सॉल्विंग

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

गीत

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

पहली चीज जो मुझे पसंद आई वह थी आखिरकार "अलविदा xml", ओह हां, मेरे लिए यह वास्तव में फिर से पैदा होने जैसा है, एक वास्तविक प्रोग्रामिंग भाषा में एक असेंबली लिखना कितना अविश्वसनीय था, यह स्वतंत्रता और प्रेरणा क्या है।

लेख ओएसजीआई और ग्रहण आरसीपी से कुछ अवधारणाओं का उपयोग करेगा, मैं उन पर ध्यान केंद्रित नहीं करूंगा ताकि मुख्य विषय से विचलित न हो।

आवेदन में स्क्रिप्ट और उदाहरण के लेख में उपयोग किए जाने वाले कुछ स्रोत कोड के साथ एक सरल परियोजना है: tynts

समस्या का पैमाना

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

इसलिए मैंने ग्रैडल को सुझाव दिया, उन्होंने मुझे आगे बढ़ने के लिए दिया, और यह शुरू हुआ।

प्रोजेक्ट संरचना विवरण

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

include "subproject-first" include "subproject-first:child-first" include "subproject-first:child-first:another-child:last-child" include "subproject-first:child-first:another-child:another-last-child" include "subproject-second" 

अब हम कमांड चलाकर अपने सिस्टम की संरचना को देख सकते हैं:

 gradle projects -q 

परिणाम:

आईडीई सेटअप

अगला कदम आईडीई में परियोजनाओं को आयात करने की क्षमता थी। ग्रेडल में विचार और ग्रहण के लिए प्लगइन्स हैं:
tynts
barabynts

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

ग्रहण प्लग-इन लेने के बाद, मैं परियोजनाओं को ठीक उसी तरह कॉन्फ़िगर करने में सक्षम था जैसा मुझे ज़रूरत थी, लेकिन मुझे परियोजनाओं को एक ग्रहण प्लग-इन के रूप में बनाना था, सेटिंग्स में प्लग इन पर निर्भरता दर्ज करें, उपयोग किए गए कंपाइलर के संस्करण को निर्दिष्ट करें। सेटिंग उदाहरण:

 project.apply plugin: 'java' project.apply plugin: 'eclipse' project.apply plugin: 'idea' project.eclipse { jdt { sourceCompatibility = '1.6' } project { //     eclipse plug-in natures 'org.eclipse.pde.PluginNature' } classpath { downloadSources = true downloadJavadoc = true // java se 1.6 jre containers.clear() containers.add("org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6") file { //  .classpath  plugin-dependencies  (      —     osgi  ) withXml { Node node = it.asNode() node.appendNode('classpathentry', [kind: 'con', path: 'org.eclipse.pde.core.requiredPlugins']) } } } } 

यही है, जैसा कि आप देख सकते हैं, ग्रहण के लिए बहुत सारी सेटिंग्स हैं, लेकिन ग्रहण एपीआई प्लगइन के माध्यम से जो नहीं किया जा सकता है वह मैन्युअल रूप से xml सेटिंग्स फ़ाइल को सही करके किया जा सकता है।

पर निर्भर करता है

अगला चरण, निर्भरता प्रबंधन: प्रलेखन ।

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

 project(":myproject") { dependencies { //    compile project(":other-my-project") //     compile fileTree(dir: "libs", include: "*.jar") //   maven  compile 'org.hibernate:hibernate-core:3.6.3.Final' } } 

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

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

संग्रह को डाउनलोड और अनपैक करें:

 //   temp      File sdkDir = getSdkDir(sdkVersion) //    project.configurations { sdk libsFromSdk } // artifactory       project.repositories { maven { url 'http://localrepo:8081/artifactory/repo' } mavenCentral() mavenLocal() } //  project.dependencies { sdk group: 'com.kontora', name: 'sdk', version: sdkVersion, ext: 'zip' } Configuration cfg = project.configurations.sdk // zip    cfg.files.each { File zipArchive -> //    project.ant.unzip src: zipArchive, dest: sdkDir.absolutePath } 

कृपया ध्यान दें कि विधानसभा के संदर्भ में ग्रैड भाषा के डडल का उपयोग करके क्रियाओं के पूरे सेट को क्रमादेशित किया जाता है। प्रोग्रामिंग भाषा में अपना निम्न-स्तरीय कोड लिखने की कोई आवश्यकता नहीं है।

अप्रयुक्त संग्रह से परियोजना के लिए निर्भरता को जोड़ना:

 project.dependencies { libsFromSdk project.fileTree(dir: "$pathToSdk/libs", include: "*.jar") … //    libsFromSdk  compile  project.compile libsFromSdk } 

और अंत में, हम संकलन के लिए अपने सभी निर्भरताएं प्राप्त करते हैं।

आई लव यू कोड, जो अपने आप में नया नहीं है

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

ट्रायम ।

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

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

प्लगइन उदाहरण:

 package org.gradle.example import org.gradle.api.Project import org.gradle.api.Plugin class MyPlugin implements Plugin<Project>{ private static final String PLUGIN_EXTENSION = 'my' Project project; @Override public void apply(Project project) { MyPlugin plugin = project.extensions.create(PLUGIN_EXTENSION, MyPlugin.class) plugin.project = project; } public void applyCommonSettings() { project.apply plugin: 'java' project.apply plugin: 'eclipse' project.apply plugin: 'idea' } } 

प्लगइन कॉल करने का उदाहरण:

 project.apply plugin: MyPlugin my{ applyCommonSettings() } 

क्या आपके पास मोती बटन के साथ बिल्कुल ऐसा ही है?

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

इसके अलावा, मैं अपने स्वयं के सत्यापनकर्ताओं को लिखने में सक्षम था जो परियोजनाओं की संरचना को मान्य करते हैं।

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

निष्कर्ष

मैं Gredl से बहुत खुश हूं, इसने 101% का भुगतान किया है और मैं चाहता हूं कि आप इस प्रणाली के साथ काम करने की खुशी को जान सकें।