😆 🚣 🏜️ बाइक से मावेन तक ⏳ 🕵🏽 👨🏽‍⚖️

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

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

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

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

"नेटबीन्स की तरह" की अवधारणा में क्या शामिल है: सभी संसाधनों की प्रतिलिपि बनाएँ (चित्र, .properties-files), सभी संबंधित पुस्तकालयों को ऊपर खींचें, प्रकट में आवश्यक जानकारी लिखें। डिफ़ॉल्ट रूप से, मावेन केवल .class फ़ाइलों को इकट्ठा करता है और जार संग्रह में अधिक कुछ नहीं होता है, और प्रकटन डरावना होता है।

इस लेख में मैं परियोजना के जीवन चक्र के चरणों के बारे में बात नहीं करूंगा। यहाँ देखें बिल्ड लाइफसाइकल का परिचय और ऊपर के लेखों में।

तो, हम सभी (हुर्रे, मैं पहले से ही इसे दे देता हूं :)) जानते हैं कि परियोजना की विधानसभा की सभी जानकारी pom.xml फ़ाइल में संग्रहीत है। निर्भरताएँ (प्रोजेक्ट और प्लगइन्स की कलाकृतियाँ) हैं, और इन प्लगइन्स का कॉन्फ़िगरेशन स्वयं, क्या और कैसे करना है, कहाँ रखना है, क्या करने के लिए अन्य जोड़तोड़ हैं। प्रत्येक प्लगइन को इसके संस्करण, नाम और जीवन चक्र चरण का संकेत देते हुए, इसके <प्लगइन /> टैग में कॉन्फ़िगर किया गया था। सभी कॉन्फ़िगरेशन को एक सामान्य <plugins /> टैग में <build /> टैग के अंदर रखा गया था, जो पूरी परियोजना के निर्माण के लिए जिम्मेदार है।

आइए नज़र डालते हैं बिंदुओं पर।

NetBeans में एक परियोजना का निर्माण

यहाँ क्या शामिल है? हाँ, हमने पहले ही तय कर लिया है: src निर्देशिका से सभी संसाधनों की प्रतिलिपि बनाना (स्रोत वहाँ हैं), लक्ष्य निर्भरता (लक्ष्य) के सभी आश्रितों को कॉपी करते हुए, जानकारी को प्रकट में जोड़ते हैं।

सभी निर्भरता की नकल मावेन-निर्भरता-प्लगइन प्लगइन द्वारा की गई, इसके विन्यास के नीचे:

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <configuration> <outputDirectory>${project.build.directory}/lib/</outputDirectory> <overWriteReleases>false</overWriteReleases> <overWriteSnapshots>false</overWriteSnapshots> <overWriteIfNewer>true</overWriteIfNewer> </configuration> <executions> <execution> <id>copy-dependencies</id> <phase>package</phase> <goals> <goal>copy-dependencies</goal> </goals> </execution> </executions> </plugin>

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

घोषणापत्र में जानकारी इस प्रकार जोड़ी गई:

 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <configuration> <archive> <manifest> <addClasspath>true</addClasspath> <classpathPrefix>lib/</classpathPrefix> <classpathLayoutType>simple</classpathLayoutType> <mainClass>com.khmb.block_v2.Block_v2App</mainClass> </manifest> <manifestEntries> <Version>${buildNumber}</Version> </manifestEntries> </archive> </configuration> </plugin>

<ClasspathPrefix /> टैग केवल इंगित करता है कि लायब्रेरीज़ को निर्देशिका निर्देशिका से खींचा जा रहा है। एक साधारण मान के साथ <classpathLayoutType /> टैग कलेक्टर को बताता है कि जार-निक्स को एक ढेर में फेंक दिया जाना चाहिए। एक रिपॉजिटरी मूल्य भी है, फिर पुस्तकालयों को मावेन रिपॉजिटरी में जोड़ा जाएगा, अर्थात्। सभी उपनिर्देशिकाओं के साथ संकुल, संस्करण, पुस्तकालय के नाम के साथ।
यह नीचे वर्णित चर $ {buildNumber} को ध्यान देने योग्य है।
निर्भरता के अलावा, प्रकट उस वर्ग को इंगित करता है जिससे कार्यक्रम लॉन्च किया जाएगा।
उपयोग किए गए प्लगइन के सभी मापदंडों का विवरण यहां है: मावेन जार प्लगइन , और बहुत सारी दिलचस्प चीजें हैं।

अगला, जार संग्रह में इकट्ठा होने से पहले, संकलित .class फ़ाइलों के साथ एक निर्देशिका में सभी संसाधनों (चित्रों और .properties फ़ाइलों) को छोड़ने के लिए आवश्यक था।

 <plugin> <artifactId>maven-resources-plugin</artifactId> <version>2.5</version> <executions> <execution> <id>copy-resources</id> <phase>validate</phase> <goals> <goal>copy-resources</goal> </goals> <configuration> <outputDirectory>${project.build.outputDirectory}/com/khmb/${project.name}</outputDirectory> <resources> <resource> <directory>${project.build.sourceDirectory}/com/khmb/${project.name}</directory> <filtering>true</filtering> <includes> <include>**/*.properties</include> </includes> </resource> <resource> <directory>${project.build.sourceDirectory}/com/khmb/${project.name}</directory> <includes> <include>**/*.png</include> </includes> </resource> </resources> </configuration> </execution> </executions> </plugin>

कोई मुश्किल नकल नहीं, बस मावेन को सब कुछ ठीक उसी तरह से रखने के लिए कहें जो वह था। लेकिन एक ख़ासियत है: अगर png फाइलें (और प्रोजेक्ट केवल इस प्रारूप में चित्रों का उपयोग करता है) तो बस उसी की नकल की जाती है, फिर .popoperties फ़ाइलों की प्रतिलिपि फ़िल्टर की जाती है, अर्थात। प्लगइन उनके अंदर दिखेगा और अगर मावेन के चर के साथ कुछ बदलने की जरूरत है, तो वह इसे बदल देगा। यह टैग पैरामीटर <फ़िल्टरिंग /> द्वारा इंगित किया गया है - सच। यही कारण है कि संसाधनों को अलग-अलग <संसाधन /> टैग में स्थान दिया गया है - यह चित्रों को फ़िल्टर करने के लिए कोई मतलब नहीं है।

परियोजना संकलन को निम्नलिखित प्लगइन द्वारा विनियमित किया जाता है:

 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.3.2</version> <configuration> <source>${jdkVersion}</source> <target>${jdkVersion}</target> </configuration> </plugin>

थोड़ी देर बाद चर $ {jdkVersion} के बारे में।

कोड में जाने के बिना असेंबली नंबरिंग को स्वचालित करें

और क्या है, इन .properties फ़ाइलों के अंदर? सब कुछ बहुत सरल है, उनमें से एक में एप्लिकेशन की संस्करण संख्या निहित है, जो रनटाइम में फैलती है और खिड़की में इस एप्लिकेशन (तथाकथित के बारे में) की जानकारी के साथ प्रदर्शित होती है।

 Application.version = ${buildNumber}

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

 <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>buildnumber-maven-plugin</artifactId> <version>1.0</version> <configuration> <format>{0}-{1,date,yyyyMMdd}</format> <items> <item>${project.version}</item> <item>timestamp</item> </items> <doCheck>true</doCheck> <doUpdate>true</doUpdate> </configuration> <executions> <execution> <phase>validate</phase> <goals> <goal>create</goal> </goals> </execution> </executions> </plugin>

संस्करण संख्या को कई हिस्सों (<प्रारूप /> टैग) से इकट्ठा किया गया है, जिनमें से प्रत्येक घुंघराले ब्रेसिज़ में संलग्न है और जावा भाषा के MessageFormat से विवरण के अनुसार बनाई गई है। प्रत्येक भाग में एक <आइटम /> टैग है जो दर्शाता है कि किस मूल्य को प्रतिस्थापित किया जाना चाहिए। वैसे, आप इसमें टेक्स्ट "buildNumber" सम्मिलित कर सकते हैं, केवल हर बार असेंबली के दौरान इस विधानसभा की संख्या उत्पन्न की जाएगी (प्रोजेक्ट फ़ाइल के रूट में मान फ़ाइल buildNumber.properties में संग्रहीत है)। मैंने मना कर दिया, क्योंकि मेरे कार्यक्रम के संचालन की निरंतर जांच के कारण संख्या बहुत बड़ी हो सकती है, आपको इसे कितनी बार चलाना है।

एक exe फ़ाइल में जार लपेटना

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

 <plugin> <groupId>com.akathist.maven.plugins.launch4j</groupId> <artifactId>launch4j-maven-plugin</artifactId> <executions> <execution> <id>l4j-clui</id> <phase>package</phase> <goals> <goal>launch4j</goal> </goals> <configuration> <headerType>gui</headerType> <outfile>target/${exeFileName}.exe</outfile> <jar>target/${project.artifactId}-${project.version}.jar</jar> <errTitle>${product.title}</errTitle> <icon>favicon.ico</icon> <classPath> <mainClass>com.khmb.block_v2.Block_v2App</mainClass> <addDependencies>true</addDependencies> <preCp>anything</preCp> </classPath> <jre> <minVersion>${jdkVersion}.0</minVersion> </jre> <versionInfo> <fileVersion>${project.version}.0</fileVersion> <txtFileVersion>${project.version}</txtFileVersion> <fileDescription>       </fileDescription> <copyright>Copyright © 2011 ${product.company}</copyright> <productVersion>${project.version}.0</productVersion> <txtProductVersion>${project.version}</txtProductVersion> <companyName>${product.company}</companyName> <productName>${product.title}</productName> <internalName>${exeFileName}</internalName> <originalFilename>${exeFileName}.exe</originalFilename> </versionInfo> </configuration> </execution> </executions> </plugin>

मैंने संकेत दिया कि jre के किस संस्करण का उपयोग किया जाना चाहिए (चर $ {jdkVersion} से मेल खाती है), इनपुट फ़ाइल, आउटपुट फ़ाइल, किस आइकन पर स्क्रू करना है, और exe फ़ाइल के बारे में जानकारी देखते समय जो जानकारी देखी जा सकती है। Jre संस्करण संख्या इस तरह क्यों लिखी गई है: $ {jdkVersion} .0? सब कुछ बहुत सरल है, लॉन्च 4 जे प्लगइन को xxx [_x] प्रारूप में एक संस्करण संख्या की आवश्यकता होती है, और pom.xml फ़ाइल के अन्य स्थान पर (संकलन प्लगइन कॉन्फ़िगरेशन में) आपको xx प्रारूप में एक संस्करण संख्या निर्दिष्ट करने की आवश्यकता है खैर, समान मापदंडों का अलग से पालन न करें? इसलिए, सामान्य भाग को एक चर में रखा गया था (अंत देखें)।

वैसे, प्लगइन के लिए इंटरनेट पर मावेन रिपॉजिटरी से खुद को खींचने के लिए (केंद्रीय भंडार में ऐसा कोई प्लगइन नहीं है), आपको एक और निर्दिष्ट करने की आवश्यकता है:

 <repositories> <repository> <id>akathist-repository</id> <name>Akathist Repository</name> <url>http://www.9stmaryrd.com/maven</url> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>akathist-repository</id> <name>Akathist Repository</name> <url>http://www.9stmaryrd.com/maven</url> </pluginRepository> </pluginRepositories>

टैग्स <repositories /> और <pluginRepositories /> प्रोजेक्ट रूट टैग के अंदर हैं, अर्थात। निर्भरता विवरण टैग और असेंबली विवरण टैग के साथ।

मर्क्यूरियल रिपॉजिटरी के साथ सिंक

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

 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-scm-plugin</artifactId> <version>1.5</version> <configuration> <!-- <username>username</username> <password>password</password> //--> <connectiontype>developerConnection</connectiontype> </configuration> <executions> <execution> <phase>validate</phase> <goals> <goal>update</goal> </goals> </execution> </executions> </plugin>

लॉगिन और पासवर्ड पैरामीटर को इस कारण से टिप्पणी की जाती है कि मैं प्राधिकरण की आवश्यकता के बिना एक स्थानीय भंडार का उपयोग करता हूं। हां, वैसे, <build /> टैग के बाहर, पैरामीटर इंगित किए जाते हैं कि हमारी रिपॉजिटरी कहां स्थित है:

 <scm> <connection>scm:hg:file:///${project.basedir}</connection> <developerConnection>scm:hg:file:///${project.basedir}</developerConnection> <url>file:///${project.basedir}</url> </scm>

कैसे, क्या और कहाँ कसने के लिए फिर से आधिकारिक दस्तावेज में वर्णित किया गया है: एससीएम कार्यान्वयन: मर्क्यूरियल । रिपॉजिटरी के लिए एक अनुरोध किया गया है, नवीनतम परिवर्तन स्वीकार किए जाते हैं, और हमारे पास परियोजना का नवीनतम संस्करण है (सक्रिय शाखा के ढांचे के भीतर, निश्चित रूप से)।

फिनिश लाइन

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

 <plugin> <artifactId>maven-assembly-plugin</artifactId> <executions> <execution> <id>assembly</id> <phase>package</phase> <goals> <goal>attached</goal> </goals> <configuration> <descriptors> <descriptor>assembly.xml</descriptor> </descriptors> </configuration> </execution> </executions> </plugin>

प्लगइन के लिए प्रलेखन संलग्न लक्ष्य का उपयोग करने की दृढ़ता से अनुशंसा करता है। संपूर्ण कॉन्फ़िगरेशन एक अलग असेंबली। Xml फ़ाइल में संग्रहीत है। यहाँ इसकी सामग्री हैं:

 <assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd"> <id>bin</id> <formats> <format>zip</format> </formats> <fileSets> <fileSet> <directory>${project.basedir}</directory> <outputDirectory>/</outputDirectory> <includes> <include>data.ini</include> <include>ReleaseNotes.txt</include> </includes> </fileSet> <fileSet> <directory>${project.basedir}</directory> <outputDirectory>/docs</outputDirectory> <includes> <include>User's guide.pdf</include> </includes> </fileSet> <fileSet> <directory>${project.build.directory}</directory> <outputDirectory>/</outputDirectory> <includes> <include>${exeFileName}.exe</include> <include>${project.artifactId}-${project.version}.jar</include> <include>lib/**</include> </includes> </fileSet> </fileSets> </assembly>

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

चर

सभी विन्यास बस इन चरों के साथ ही चल रहे हैं। अच्छा, आप बताइए।
- $ {project.basedir} - मावेन में प्रोजेक्ट रूट डायरेक्टरी के लिए पथ संग्रहीत करता है;
- $ {project.build.directory} - आमतौर पर मावेन पर परियोजना के लक्ष्य उपनिर्देशिका से मेल खाती है;
- $ {project.build.outputDirectory} - संकलित .class फ़ाइलों को जोड़ा जाता है, जहां लक्ष्य के अंदर निर्देशिका से मेल खाती है। आमतौर पर इसका नाम कक्षाएं हैं, और यह अपनी सामग्री से है कि अंतिम जार संग्रह एकत्र किया जाता है।
- $ {project.name} - हमारी कलाकृति का नाम, <विरूपण साक्ष्य /> टैग से लिया गया है
- $ {project.version} - विरूपण साक्ष्य संस्करण, टैग मूल्य <संस्करण />

शेष चर हाथ से निर्धारित किए गए थे, <गुण /> जड़ के अंदर टैग <परियोजना /> pom.xml फ़ाइल का टैग। यहाँ इसकी सामग्री हैं:

 <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <exeFileName>block</exeFileName> <product.title> </product.title> <product.company>   :)</product.company> <product.year>2011</product.year> <jdkVersion>1.6</jdkVersion> </properties>

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

निष्कर्ष

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

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

बाइक से मावेन तक