ग्रेडल टास्क का विवरण

नि: शुल्क पुस्तक भवन और ग्रैडल के साथ परीक्षण के दूसरे अध्याय का अनुवाद

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

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

कार्य की घोषणा

कार्य बनाने का एक आसान तरीका है। आपको केवल कार्य का नाम निर्दिष्ट करना है:

उदाहरण 1. अकेले नाम से किसी कार्य की घोषणा करना

task hello 

gradle hello कमांड gradle hello करने के बाद, हमें परिणाम मिलता है:

उदाहरण 2. किसी नए कार्य पर होने वाली रिपोर्ट

 ------------------------------------------------------------ All tasks runnable from root project ------------------------------------------------------------ Build Setup tasks ----------------- init - Initializes a new Gradle build. [incubating] wrapper - Generates Gradle wrapper files. [incubating] Help tasks ---------- dependencies - Displays all dependencies declared in root project '__project'. dependencyInsight - Displays the insight into a specific dependency in root project '__project'. help - Displays a help message projects - Displays the sub-projects of root project '__project'. properties - Displays the properties of root project '__project'. tasks - Displays the tasks runnable from root project '__project'. Other tasks ----------- hello 

कार्य क्रिया

gradle hello कमांड के साथ अपना कार्य करना अभी भी कोई परिणाम नहीं gradle hello , क्योंकि हमने इसके लिए एक भी एक्शन नहीं दिया है । बाएं शिफ्ट ऑपरेटर का उपयोग करके एक ऑपरेशन सौंपा जा सकता है:

उदाहरण 3. एक साधारण ऑपरेशन जोड़ना

 task hello << { println 'hello, world' } 

ऑपरेटर्स जैसे कि << (जावा से "लेफ्ट शिफ्ट") को ग्रोवी में ओवरलोड किया जा सकता है ताकि वे उन वस्तुओं के आधार पर व्यवहार को बदल सकें जिनके साथ वे काम करते हैं। इस मामले में, << ग्रैड में ओवरलोडेड है जो कि कार्य करने वाले कार्यों की सूची में कोड के एक ब्लॉक को जोड़ने के लिए है। एक बाईं पारी doLast() विधि के बराबर है, जिसके बारे में हम नीचे चर्चा करेंगे।

अब हमारे पास एक अतिरिक्त तरीके से ऑपरेशन कोड को जोड़ने की लचीली क्षमता है, जो हमने बनाई गई कार्य वस्तु का जिक्र करते हुए किया है:

उदाहरण 4. कार्य संचालन को एक बार में जोड़ना

 task hello hello << { print 'hello, ' } hello << { println 'world' } 

अब हमें फिर से परिचित बनाने का परिणाम मिला है:

उदाहरण 5. ऑपरेशन के साथ निर्माण का परिणाम एक समय में एक जोड़ा गया

 d:\project>gradle hello :hello hello, world BUILD SUCCESSFUL Total time: 1.916 secs 

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

कार्य विन्यास

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

उदाहरण 6. विन्यास और कार्य संचालन को मिलाना

 task initializeDatabase initializeDatabase << { println 'connect to database' } initializeDatabase << { println 'update database schema' } initializeDatabase { println 'configuring database connection' } 

ऐसी बिल्ड फ़ाइल चलाने से, हमें एक परिणाम मिलता है जो हमारे लिए अतार्किक लगता है:

उदाहरण 7. ऊपर बनाई गई बिल्ड फ़ाइल को निष्पादित करने का परिणाम

 d:\project>gradle initializeDatabase configuring database connection :initializeDatabase connect to database update database schema BUILD SUCCESSFUL Total time: 3.088 secs 

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

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

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

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

कॉन्फ़िगरेशन क्लोजर उसी तरह additive हैं जैसे ऑपरेशन क्लोजर। इसलिए, हम पिछले उदाहरण के लिए बिल्ड फ़ाइल के कोड को नीचे वर्णित तरीके से लिख सकते हैं, जबकि निष्पादन का परिणाम पहले जैसा होगा:

उदाहरण 8. कॉन्फ़िगरेशन ब्लॉक जोड़ना

 task initializeDatabase initializeDatabase << { println 'connect to database' } initializeDatabase << { println 'update database schema' } initializeDatabase { print 'configuring ' } initializeDatabase { println 'database connection' } 

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

जब ग्रेड फ़ाइल लॉन्च की जाती है, तो बिल्ड कॉन्फ़िगरेशन कोड पूरी तरह से निष्पादित होता है, भले ही निष्पादन चरण में कोई भी कार्य लॉन्च किया जाएगा।

कार्य वस्तुएं हैं

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

डिफ़ॉल्ट रूप से, प्रत्येक नए कार्य को DefaultTask टाइप किया जाता है। जिस प्रकार जावा में प्रत्येक वर्ग java.lang.Object से विरासत में मिलता है, उसी प्रकार ग्रेडेड में प्रत्येक कार्य किसी दिए गए प्रकार से विरासत में मिलता है - यहाँ तक कि वे कार्य जो एक नए प्रकार का निर्माण करके DefaultTask की क्षमताओं का विस्तार करते हैं। वास्तव में, DefaultTask कार्य कुछ विशिष्ट नहीं करते हैं, जैसे कोड संकलित करना या फ़ाइलों की प्रतिलिपि बनाना। हालाँकि, उनके पास कार्यक्षमता है जो ग्रेडल प्रोजेक्ट प्रोग्रामिंग मॉडल के साथ बातचीत करने के लिए आवश्यक है। ग्रैडल में प्रत्येक कार्य के तरीकों और गुणों पर विचार करें।

DefaultTask तरीके

निर्भरता (कार्य)

कॉलिंग कार्य के लिए, एक निर्भरता कार्य जोड़ता है। एक निर्भरता कार्य हमेशा उस कार्य से पहले चलाया जाता है जो उस पर निर्भर करता है। विधि को कई तरीकों से बुलाया जा सकता है। नीचे दिए गए कोड उदाहरण से पता चलता है कि हम loadTestData पर createSchema कार्य की निर्भरता कैसे निर्धारित कर सकते हैं:

उदाहरण 9. dependsOn विधि को कॉल करने के विभिन्न तरीके

 task createSchema //   'loadTestData'  'createSchema' //  ,  ,   task loadTestData { dependsOn createSchema } //       task loadTestData { dependsOn << createSchema } //    ,    (   ) task loadTestData { dependsOn 'createSchema' } //    - task loadTestData loadTestData.dependsOn createSchema //      task loadTestData(dependsOn: createSchema) 

एक कार्य कई कार्यों पर निर्भर हो सकता है। अगर loadTestData कार्य createSchema और compileTestClasses पर निर्भर करता compileTestClasses , तो हम कोड को इस प्रकार लिखते हैं:

उदाहरण 10. कई निर्भरता के लिए निर्भरता विधि को कॉल करने के विभिन्न तरीके

 task compileTestClasses task createSchema //     task loadTestData { dependsOn << compileTestClasses dependsOn << createSchema } //  ,     task loadTestData { dependsOn compileTestClasses, createSchema } //    - task loadTestData loadTestData.dependsOn compileTestClasses, createSchema //      //      Groovy task loadTestData(dependsOn: [ compileTestClasses, createSchema ]) 

doFirst (बंद)

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

doFirst विधि को सीधे कार्य ऑब्जेक्ट के लिए कहा जा सकता है, इसे एक क्लोजर पास करते हुए जिसमें कोड होता है जिसे वर्तमान कार्य संचालन से पहले निष्पादित किया जाएगा।

जैसा कि हमने पहले ही कहा था, एक करीबी एक कोडी का ग्रूवी ब्लॉक है जो घुंघराले ब्रेसिज़ की एक जोड़ी के बीच होता है। एक बंद को किसी अन्य वस्तु की तरह एक विधि को पारित किया जा सकता है। विधियों में बंद अभिव्यक्तियों को पारित करने की क्षमता एक ग्रूवी शैली की विशेषता है।

उदाहरण 11. doFirst विधि को कॉल करना

 task setupDatabaseTests << { //      println 'load test data' } setupDatabaseTests.doFirst { println 'create schema' } 

उदाहरण 12. अंतिम बिल्ड फ़ाइल को निष्पादित करने का परिणाम

 d:\project>gradle setupDatabaseTests :setupDatabaseTests create schema load test data BUILD SUCCESSFUL Total time: 1.935 secs 

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

उदाहरण 13. कार्य विन्यास ब्लॉक के अंदर doFirst विधि को कॉल करना

 task setupDatabaseTests << { println 'load test data' } setupDatabaseTests { doFirst { println 'create schema' } } 

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

उदाहरण 14. बार-बार doFirst कॉल्स में doFirst गुण होता है

 task setupDatabaseTests << { println 'load test data' } setupDatabaseTests.doFirst { println 'create database schema' } setupDatabaseTests.doFirst { println 'drop database schema' } 

उदाहरण 15. पिछले उदाहरण का परिणाम

 d:\project>gradle setupDatabaseTests :setupDatabaseTests drop database schema create database schema load test data BUILD SUCCESSFUL Total time: 3.126 secs 

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

अब तक, हमारे उदाहरणों ने एक बहुत ही सरल वाक्यविन्यास का उपयोग किया है जो बताता है कि ग्रैडल बार-बार क्लोजर जोड़कर कैसे काम करता है। सबसे अधिक संभावना है, एक वास्तविक निर्माण में हम कार्य को निम्नानुसार व्यवस्थित करते हैं (सभी समान, वास्तविक परीक्षण कार्यों के बजाय हम println ऑपरेटरों का उपयोग करते हैं):

उदाहरण 16. निरस्त करने के बाद बार-बार doFirst कॉल

 //    (    ) task setupDatabaseTests << { println 'load test data' } //    ( ,     ) setupDatabaseTests { doFirst { println 'create database schema' } doFirst { println 'drop database schema' } } 

कृपया ध्यान दें कि हमने एक ही कॉन्फ़िगरेशन ब्लॉक के अंदर कई doFirst कॉल एक साथ रखी हैं क्योंकि प्रारंभिक ऑपरेशन पहले से ही setupDatabaseTests कार्य में जोड़ा गया है।

doLast (बंद करना)

doLast विधि doLast विधि के समान है, केवल अंतर यह है कि यह ऑपरेशन के अंत में व्यवहार जोड़ता है, न कि शुरुआत में। यदि आपको किसी कार्य को पूरा करने के बाद कोड को ब्लॉक करने की आवश्यकता है, तो आप निम्न कार्य कर सकते हैं:

उदाहरण 17. DoLast विधि का उपयोग करना

 task setupDatabaseTests << { println 'create database schema' } setupDatabaseTests.doLast { println 'load test data' } 

उदाहरण 18. DoLast कॉलबैक additive हैं

 task setupDatabaseTests << { println 'create database schema' } setupDatabaseTests.doLast { println 'load test data' } setupDatabaseTests.doLast { println 'update version table' } 

जैसा कि पहले उल्लेख किया गया है, किसी कार्य के अनुभाग ऑपरेशन में , << ऑपरेटर doLast() विधि को कॉल करने का एक और तरीका है।

केवल (बंद)

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

ग्रूवी में, क्लोजर के अंदर अंतिम अभिव्यक्ति इसके रिटर्न मूल्य को निर्धारित करती है, भले ही कोई return । ग्रूवी पद्धति, जिसमें केवल एक अभिव्यक्ति को परिभाषित किया गया है, एक फ़ंक्शन है जो इस अभिव्यक्ति का मूल्य लौटाता है।

उदाहरण 19. केवल निर्माण विधि का उपयोग करके फ़ाइल बनाएँ

 task createSchema << { println 'create database schema' } task loadTestData(dependsOn: createSchema) << { println 'load test data' } loadTestData.onlyIf { System.properties['load.data'] == 'true' } 

उदाहरण 20. बिल्ड फ़ाइल शुरू करने के लिए दो विकल्प। परिणामों में अंतर पर ध्यान दें।

 d:\project>gradle loadTestData :createSchema create database schema :loadTestData SKIPPED BUILD SUCCESSFUL Total time: 4.361 secs d:\project>gradle -Dload.data=true loadTestData :createSchema create database schema :loadTestData load test data BUILD SUCCESSFUL Total time: 2.005 secs 

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

डिफ़ॉल्ट गुण

didWork

प्रकार boolean की एक संपत्ति जो इंगित करती है कि क्या कार्य सफलतापूर्वक पूरा हुआ। सभी कार्य पूर्ण होने के समय didWork पर सेट नहीं होते हैं। हालाँकि, कुछ कार्य, जैसे कि Compile , Copy और Delete , इस संपत्ति के मूल्य को सूचना प्रसारित करने के लिए सेट करते हैं कि उनके संचालन को सफलतापूर्वक या त्रुटियों के साथ पूरा किया गया था। एक मान की गणना जो यह दर्शाता है कि कार्य पहले ही पूरा हो चुका है, विभिन्न कार्यों के लिए विशिष्ट है। आपके द्वारा बनाए गए असेंबली कोड के निष्पादन के परिणामों को दर्शाने के लिए आप अपने कार्य में didWork मान सेट कर सकते हैं:

उदाहरण 21. संकलन सफल होने पर मामले के लिए एक ईमेल भेजना

 apply plugin: 'java' task emailMe(dependsOn: compileJava) << { if (tasks.compileJava.didWork) { println 'SEND E-MAIL ANNOUNCING SUCCESS' } } 

उदाहरण 22. डॉकवर्क का उपयोग करके निर्माण के परिणाम

 d:\project>gradle emailMe :compileJava :emailMe SEND E-MAIL ANNOUNCING SUCCESS BUILD SUCCESSFUL Total time: 4.232 secs 

सक्षम

एक boolean संपत्ति जो इंगित करती है कि क्या कार्य चलेगा। आप enabled संपत्ति को false सेट करके किसी कार्य के निष्पादन को अक्षम कर सकते हैं। कार्य निर्भरताएं उसी क्रम में निष्पादित होंगी जैसे कि कार्य अक्षम नहीं किया गया था।

उदाहरण 23. किसी कार्य को अक्षम करना

 task templates << { println 'process email templates' } task sendEmails(dependsOn: templates) << { println 'send emails' } sendEmails.enabled = false 

उदाहरण 24. एक अक्षम कार्य के साथ बनाएँ। कृपया ध्यान दें कि निर्भरता अभी भी शुरू होती है।

 d:\project>gradle -b enabled.gradle sendEmails :templates process email templates :sendEmails SKIPPED BUILD SUCCESSFUL Total time: 3.271 secs 

-B कमांड लाइन पैरामीटर ग्रैड को डिफ़ॉल्ट फ़ाइल के अलावा अन्य बिल्ड फ़ाइल बताता है। डिफ़ॉल्ट रूप से, build.gradle नामक एक फ़ाइल की build.gradle , लेकिन यह कमांड लाइन विकल्प हमें एक अलग बिल्ड फ़ाइल निर्दिष्ट करने की अनुमति देता है।

पथ

एक स्ट्रिंग प्रकार की संपत्ति जिसमें कार्य का पूर्ण पथ है। डिफ़ॉल्ट रूप से, कार्य पथ उसके सामने एक बृहदान्त्र के साथ कार्य का नाम है।

उदाहरण 25. एक एकल-स्तरीय बिल्ड फ़ाइल जो इसमें परिभाषित एकल कार्य का पथ प्रदर्शित करती है

 task echoMyPath << { println "THIS TASK'S PATH IS ${path}" } 

उदाहरण 26. पिछली बिल्ड फ़ाइल के परिणाम

 d:\project>gradle echoMyPath :echoMyPath THIS TASK'S PATH IS :echoMyPath BUILD SUCCESSFUL Total time: 3.135 secs 

सामने एक कोलन इंगित करता है कि कार्य बिल्ड फ़ाइल के शीर्ष स्तर पर परिभाषित किया गया है। हालांकि, शीर्ष स्तर पर कार्यों का पता लगाना वैकल्पिक है। ग्रैड आश्रित उपप्रोजेक्ट या नेस्टेड बिल्ड का समर्थन करता है। यदि कार्य subProject नामक नेस्टेड बिल्ड में परिभाषित किया गया है, तो पथ होगा :subProject:echoMyPath ।

लकड़हारा

आंतरिक ग्रेडल logger ऑब्जेक्ट का संदर्भ। org.slf4j.Logger , logger कई अतिरिक्त स्तरों के साथ org.slf4j.Logger इंटरफ़ेस को लागू करता है। logger वस्तु द्वारा समर्थित लॉगिंग स्तर नीचे वर्णित हैं। नीचे दिए गए मानों में से एक लॉगिंग स्तर सेट करना, बाद के सभी स्तरों पर लॉगिंग और QUIET को छोड़कर सक्षम बनाता है:

• DEBUG विस्तृत लॉगिंग संदेशों के लिए जिन्हें बिल्ड डेवलपर की आवश्यकता होती है, हालांकि, उन्हें उस समय प्रदर्शित नहीं किया जाना चाहिए जब बिल्ड सामान्य मोड में चलता है। यदि इस स्तर का चयन किया जाता है, तो ग्रैडल स्वचालित रूप से उन्नत प्रारूप का उपयोग करता है, जो प्रत्येक संदेश में टाइमस्टैम्प, लॉगिंग स्तर और लॉगिंग करने वाले कार्य का नाम सम्मिलित करता है। शेष स्तर एक छोटे संदेश प्रारूप का उपयोग करते हैं।
• INFO । कम जानकारीपूर्ण बिल्ड संदेशों की आवश्यकता होती है जो बिल्ड निष्पादन के दौरान द्वितीयक भूमिका निभाते हैं।
• LIFECYCLE । बिल्ड के जीवन चक्र में परिवर्तन और उपकरण को निष्पादित करने की प्रक्रिया के बारे में असंगत संदेश जो परियोजना की विधानसभा को लॉन्च करता है। आमतौर पर ग्रेडेल द्वारा ही उत्पन्न किया गया। जब स्तर -q कमांड लाइन विकल्प के बिना ग्रेड शुरू होता है तो यह स्तर डिफ़ॉल्ट रूप से उपयोग किया जाता है। , println .
• WARN . , , . WARN , QUIET .
• QUIET . , -q . ( -q QUIET ). , System.out.println . QUIET , WARN .
• ERROR। दुर्लभ, लेकिन महत्वपूर्ण संदेश जो लॉगिंग के सभी स्तरों पर प्रदर्शित होते हैं। संदेश त्रुटियों के साथ बिल्ड के पूरा होने के बारे में सूचित करते हैं। यदि ERRORलॉगिंग का वर्तमान स्तर है, System.out.printlnतो कंसोल विंडो में कॉल प्रदर्शित नहीं की जाएंगी।

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

 task logLevel << { def levels = ['DEBUG', 'INFO', 'LIFECYCLE', 'QUIET', 'WARN', 'ERROR'] levels.each { level -> logging.level = level def logMessage = "SETTING LogLevel=${level}" logger.error logMessage logger.error '-' * logMessage.size() logger.debug 'DEBUG ENABLED' logger.info 'INFO ENABLED' logger.lifecycle 'LIFECYCLE ENABLED' logger.warn 'WARN ENABLED' logger.quiet 'QUIET ENABLED' logger.error 'ERROR ENABLED' println 'THIS IS println OUTPUT' logger.error ' ' } } 

उदाहरण 28. पिछली बिल्ड फ़ाइल को निष्पादित करने का परिणाम

 d:\project>gradle logLevel 19:35:44.677 [LIFECYCLE] [class org.gradle.TaskExecutionLogger] 19:35:44.699 [ERROR] [org.gradle.api.Task] SETTING LogLevel=DEBU 19:35:44.732 [ERROR] [org.gradle.api.Task] --------------------- 19:35:44.747 [DEBUG] [org.gradle.api.Task] DEBUG ENABLED 19:35:44.760 [INFO] [org.gradle.api.Task] INFO ENABLED 19:35:44.775 [LIFECYCLE] [org.gradle.api.Task] LIFECYCLE ENABLED 19:35:44.788 [WARN] [org.gradle.api.Task] WARN ENABLED 19:35:44.801 [QUIET] [org.gradle.api.Task] QUIET ENABLED 19:35:44.812 [ERROR] [org.gradle.api.Task] ERROR ENABLED 19:35:44.857 [QUIET] [system.out] THIS IS println OUTPUT 19:35:44.868 [ERROR] [org.gradle.api.Task] SETTING LogLevel=INFO --------------------- INFO ENABLED LIFECYCLE ENABLED WARN ENABLED QUIET ENABLED ERROR ENABLED THIS IS println OUTPUT SETTING LogLevel=LIFECYCLE -------------------------- LIFECYCLE ENABLED WARN ENABLED QUIET ENABLED ERROR ENABLED THIS IS println OUTPUT SETTING LogLevel=QUIET ---------------------- QUIET ENABLED ERROR ENABLED THIS IS println OUTPUT SETTING LogLevel=WARN --------------------- WARN ENABLED QUIET ENABLED ERROR ENABLED THIS IS println OUTPUT SETTING LogLevel=ERROR ---------------------- ERROR ENABLED BUILD SUCCESSFUL Total time: 2.184 secs 

लॉगिंग

संपत्ति loggingहमें लॉगिंग के स्तर को नियंत्रित करने की अनुमति देती है। जैसा कि पहले से ही संपत्ति केlogger लिए उदाहरण में दिखाया गया है , बिल्ड का लॉगिंग स्तर संपत्ति का उपयोग करके प्राप्त और संशोधित किया जा सकता है logging.level।

विवरण

संपत्ति description, जैसा कि नाम से पता चलता है, मानव समझ के लिए उपलब्ध मेटाडेटा की एक छोटी राशि के साथ कार्य के उद्देश्य का वर्णन करता है। मूल्य descriptionकई मायनों में निर्दिष्ट किया जा सकता है:

उदाहरण 29. एक ही समय में, हम कार्य विवरण और व्यवहार को परिभाषित करते हैं

 task helloWorld(description: 'Says hello to the world') << { println 'hello, world' } 

उदाहरण 30. कार्य व्यवहार घोषित करने और विवरण को परिभाषित करने के दो तरीके

 task helloWorld << { println 'hello, world' } helloWorld { description 'Says hello to the world' } //    helloWorld.description 'Says hello to the world' 

temporaryDir

संपत्ति temporaryDirएक ऐसी वस्तु लौटाती है जो Fileवर्तमान बिल्ड फ़ाइल के अस्थायी निर्देशिका को संदर्भित करती है। ऐसी निर्देशिका कार्य के मध्यवर्ती परिणामों को अस्थायी रूप से संग्रहीत करने या उन फ़ाइलों को व्यवस्थित करने के लिए बनाई जाती है, जो कार्य संसाधित करेगा।

गतिशील गुण

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

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

उदाहरण 31. बिल्ड फ़ाइल, जो एक गतिशील संपत्ति का एक उदाहरण दिखाता है

 task copyFiles { //    ,   // (     ) fileManifest = [ 'data.csv', 'config.json' ] } task createArtifact(dependsOn: copyFiles) << { println "FILES IN MANIFEST: ${copyFiles.fileManifest}" } 

उदाहरण 32. पिछले उदाहरण में बिल्ड फ़ाइल को निष्पादित करने का परिणाम है

 d:\project>gradle -q createArtifact FILES IN MANIFEST: [data.csv, config.json] 

कार्यों के प्रकार

जैसा कि हमने पहले कहा, सेक्शन में ऑब्जेक्ट्स हैं , प्रत्येक कार्य का एक प्रकार है। प्रकार के अलावा DefaultTask, प्रतिलिपि बनाने, संग्रह करने, कार्यक्रम चलाने और अन्य कार्यों के लिए अन्य प्रकार के कार्य हैं। एक कार्य प्रकार की घोषणा करना एक ऑब्जेक्ट-ओरिएंटेड भाषा में बेस क्लास से विरासत में मिला हुआ बहुत कुछ है। इस प्रकार, विरासत को लागू करने से, आपको तुरंत अपने कार्य में कुछ गुण और तरीके मिलते हैं। यह वाक्यविन्यास कार्यों की परिभाषा को बहुत छोटा करता है, जबकि संभावनाएं अभी भी महान हैं।

कार्यों के पूर्ण प्रलेखन पर विचार यहां प्रस्तुत सामग्री के दायरे से परे है, लेकिन फिर भी हम उपयोग के उदाहरणों के साथ कई महत्वपूर्ण प्रकारों पर विचार करेंगे।

प्रतिलिपि

कार्य Copyएक स्थान से दूसरे स्थान पर फ़ाइलों की प्रतिलिपि बनाता है। सरलतम मामले में, यह नाम मास्क का उपयोग करके फ़ाइलों को शामिल करने या बाहर करने पर कुछ अतिरिक्त प्रतिबंधों के साथ, एक निर्देशिका से दूसरे में फ़ाइलों की प्रतिलिपि बनाता है:

उदाहरण 33. किसी कार्य का उपयोग करने का सबसे सरल उदाहरण Copy

 task copyFiles(type: Copy) { from 'resources' into 'target' include '**/*.xml', '**/*.txt', '**/*.properties' } 

जार

कार्य Jarसंसाधन फ़ाइलों से जार फ़ाइल बनाता है। एक प्रसिद्ध नाम के साथ इस प्रकार का एक कार्य Jarमॉड्यूल में परिभाषित किया गया है 'java'। कार्य * * .class फ़ाइलों और संसाधनों को एक जार फ़ाइल में प्रोजेक्ट के नाम के साथ सामान्य प्रकट का उपयोग करते हुए पैक करता है। परिणाम निर्देशिका में सहेजा गया है build/libs। यह कार्य अत्यधिक लचीला है।

उदाहरण 34. किसी कार्य का उपयोग करने का सबसे सरल उदाहरण Jar

 apply plugin: 'java' task customJar(type: Jar) { manifest { attributes firstKey: 'firstValue', secondKey: 'secondValue' } archiveName = 'hello.jar' destinationDir = file("${buildDir}/jars") from sourceSets.main.output } 

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

destinationDirएक बहुत ही सरल अभिव्यक्ति दी गई है। यह अधिक स्वाभाविक होगा यदि संपत्ति को destinationDirएक स्ट्रिंग सौंपा गया था । लेकिन संपत्ति वस्तुओं के साथ काम करती है java.io.File। बचाव के लिए तरीका आता हैfile(), जो ग्रेड फ़ाइल के बिल्ड कोड में हमेशा उपलब्ध होता है। यह किसी स्ट्रिंग को ऑब्जेक्ट में कनवर्ट करता है File।

याद रखें, आप हमेशा ऐसे दस्तावेज़ पा सकते हैं docs/dsl/index.htmlजो मानक ग्रेड सुविधाओं का वर्णन करते हैं, जैसे कि एक कार्य Jar। कार्य की सभी संभावनाओं का विवरण Jarहमारे अध्याय के दायरे से परे है।

JavaExec

कार्य JavaExecएक विधि के साथ एक जावा वर्ग शुरू करता है main()। कंसोल जावा एप्लिकेशन चलाना एक उपद्रव हो सकता है। हालाँकि, यह कार्य जावा कंसोल अनुप्रयोगों को आपके बिल्ड में एकीकृत करके असुविधा को समाप्त करता है:

उदाहरण 35. ग्रैडल कार्य एक जावा कंसोल एप्लिकेशन लॉन्च करता है (उदाहरण javaexec-task से लिया गया है )

 apply plugin: 'java' repositories { mavenCentral() } dependencies { compile 'commons-codec:commons-codec:1.6' runtime 'commons-codec:commons-codec:1.6' } task encode(type: JavaExec, dependsOn: classes) { main = 'org.gradle.example.commandline.MetaphoneEncoder' args = "The rain in Spain falls mainly in the plain".split().toList() classpath sourceSets.main.output.classesDir classpath configurations.runtime } 

 package org.gradle.example.commandline; import org.apache.commons.codec.language.Metaphone; public class MetaphoneEncoder { public static void main(String args[]) { Metaphone codec = new Metaphone(); String phrase = ""; String encoded = ""; for (String s : args) { phrase += s.toUpperCase() + " "; encoded += codec.encode(s) + " "; } System.out.println("PHRASE =" + phrase); System.out.println("ENCODED=" + encoded); } } 

encode classpath configurations.runtime . configurations , . runtime , . , ( compile ), , , , , . configurations Gradle , , .

बिल्ड फ़ाइल में Apache Commons Codec लाइब्रेरी पर एक बाहरी निर्भरता घोषित की गई है। हम अपनी जावा फ़ाइल संकलित करते हैं, फिर संकलित .class फ़ाइल और JAR निर्भरता के पथ का उपयोग करके एप्लिकेशन लॉन्च कमांड लाइन बनाते हैं। बिल्ड फ़ाइल में, उस वर्ग को निर्दिष्ट करें जिसमें main()( org.gradle.example.commandline.MetaphoneEncoder) विधि लॉन्च की जाएगी , इसे सूची के रूप में कमांड लाइन पैरामीटर दें, और आवश्यक तत्वों को इंगित करें classpath। इस स्थिति में, हम सशर्त रूप से sourceSetsकॉन्फ़िगरेशन में घोषित मुख्य निर्भरता और उपलब्ध सभी वर्गों का उल्लेख कर सकते हैं runtime। उदाहरण में वर्णित कार्य परियोजना निर्देशिका में स्थैतिक निर्भरता सहित विभिन्न रिपॉजिटरी से कई अन्य निर्भरता को परिभाषित करने पर भी काम करेगा।

कस्टम कार्य प्रकार

कभी-कभी ग्रेडेल के अंतर्निहित कार्यों की क्षमताएं आपकी समस्या को हल करने के लिए पर्याप्त नहीं हो सकती हैं। फिर एक कस्टम कार्य बनाना सबसे स्पष्ट तरीका होगा जिसे आप अपने निर्माण को विकसित करते समय लागू कर सकते हैं। ग्रैडल आपको कई तरीकों से ऐसा करने की अनुमति देता है। हम दो सबसे आम पर विचार करेंगे।

एक बिल्ड फ़ाइल में एक कस्टम कार्य प्रकार को परिभाषित करना

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

उदाहरण 36. MySQL डेटाबेस में प्रश्नों को निष्पादित करने के लिए एक कस्टम कार्य ( कस्टम-कार्य उदाहरण से

 task createDatabase(type: MySqlTask) { sql = 'CREATE DATABASE IF NOT EXISTS example' } task createUser(type: MySqlTask, dependsOn: createDatabase) { sql = "GRANT ALL PRIVILEGES ON example.* TO exampleuser@localhost IDENTIFIED BY 'passw0rd'" } task createTable(type: MySqlTask, dependsOn: createUser) { username = 'exampleuser' password = 'passw0rd' database = 'example' sql = 'CREATE TABLE IF NOT EXISTS users (id BIGINT PRIMARY KEY, username VARCHAR(100))' } class MySqlTask extends DefaultTask { def hostname = 'localhost' def port = 3306 def sql def database def username = 'root' def password = 'password' @TaskAction def runQuery() { def cmd if(database) { cmd = "mysql -u ${username} -p${password} -h ${hostname} -P ${port} ${database} -e " } else { cmd = "mysql -u ${username} -p${password} -h ${hostname} -P ${port} -e " } project.exec { commandLine = cmd.split().toList() + sql } } } 

MySqlTask DefaultTask . DefaultTask , . ( , DefaultTask . . , .) Groovy, ( hostname , database , sql ..). runQuery() , @TaskAction . runQuery() .

, , MySqlTask . , . ( username password , , ), , , . createDatabase createUser SQL-, .

createTable username , password database . , , . , , Gradle.

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

जब उपयोगकर्ता कार्य का तर्क बिल्ड फ़ाइल की उचित सीमाओं से आगे बढ़ता है, तो हम इसे buildSrcपरियोजना की जड़ में स्थित निर्देशिका में स्थानांतरित कर सकते हैं । यह निर्देशिका स्वचालित रूप से संकलित की जाती है और निर्माण के वर्गपथ में जोड़ दी जाती है। हम पिछले उदाहरण को संशोधित करेंगे, जिसमें हम उपयोग करेंगे buildSrc:

उदाहरण 37. बाहरी फ़ाइल में परिभाषित उपयोगकर्ता कार्य का उपयोग करके फ़ाइल बनाएँ

 task createDatabase(type: MySqlTask) { sql = 'CREATE DATABASE IF NOT EXISTS example' } task createUser(type: MySqlTask, dependsOn: createDatabase) { sql = "GRANT ALL PRIVILEGES ON example.* TO exampleuser@localhost IDENTIFIED BY 'passw0rd'" } task createTable(type: MySqlTask, dependsOn: createUser) { username = 'exampleuser' password = 'passw0rd' database = 'example' sql = 'CREATE TABLE IF NOT EXISTS users (id BIGINT PRIMARY KEY, username VARCHAR(100))' } 

उदाहरण 38. किसी निर्देशिका में उपयोगकर्ता कार्य को परिभाषित करना buildSrc

 import org.gradle.api.DefaultTask import org.gradle.api.tasks.TaskAction class MySqlTask extends DefaultTask { def hostname = 'localhost' def port = 3306 def sql def database def username = 'root' def password = 'password' @TaskAction def runQuery() { def cmd if(database) { cmd = "mysql -u ${username} -p${password} -h ${hostname} -P ${port} ${database} -e " } else { cmd = "mysql -u ${username} -p${password} -h ${hostname} -P ${port} -e " } project.exec { commandLine = cmd.split().toList() + sql } } } 

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

, - Gradle. — , -, . — buildSrc , . — - -. — , Java Goovy. Gradle — , .

39. Gradle, , buildSrc

 . ├── build.gradle ├── buildSrc │ └── src │ └── main │ └── groovy │ └── org │ └── gradle │ └── example │ └── task │ └── MySqlTask.groovy 

अब तक, हमने ग्रेड बिल्ड स्क्रिप्ट्स में या buildSrcग्रूवी कोड के रूप में एक निर्देशिका में सीधे कोड लिखकर कार्य बनाए हैं । यह दृष्टिकोण समस्याओं के अध्ययन के लिए अच्छा है, क्योंकि यह उनकी सभी विशेषताओं का विस्तृत विवरण प्रदान करता है। हालाँकि, आपके द्वारा उपयोग किए जाने वाले अधिकांश कार्य आपके द्वारा नहीं लिखे जाएंगे। वे बाहरी मॉड्यूल से आयात किए जाएंगे। जावा में

कंसोल एप्लिकेशन को असेंबल करने के सबसे सरल उदाहरण में HelloWorld, बिल्ड फ़ाइल निम्नानुसार है:

 apply plugin: 'java' 

Java, - , . , doFirst() doLast() , . Gradle . Gradle , , Gradle DSL (DSL — Domain Specific Language), Groovy.

, Gradle , tasks properties . . Gradle DSL.

निष्कर्ष

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

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

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

जिन लोगों के पास पाठ को सुधारने के लिए विचार हैं,
साथ ही जो त्रुटियां पाते हैं, उनका
स्वागत है GitHub ।

टाइपो खोजने के लिए निकिता_रोगत्नेव को विशेष धन्यवाद ।