1.1 Maven मध्ये तयार करण्यासाठी प्लगइनची सूची
मावेनमधील असेंब्ली अतिशय लवचिकपणे कॉन्फिगर केली जाऊ शकते. मॅवेन डेव्हलपर्सनी विशेषत: डझनभर प्लगइन तयार केले आहेत, ज्याचा वापर करून तुम्ही विविध बिल्ड्स अतिशय लवचिकपणे कॉन्फिगर करू शकता. त्यापैकी सर्वात लोकप्रिय खालील सारणीमध्ये दर्शविले आहेत:
प्लगइन | वर्णन | |
---|---|---|
१ | maven-compiler-plugin | Java संकलन व्यवस्थापित करते |
2 | maven-resources-plugin | असेंब्लीमध्ये संसाधनांचा समावेश नियंत्रित करते |
3 | maven स्रोत प्लगइन | स्रोत कोड असेंब्लीमध्ये समाविष्ट आहे की नाही हे नियंत्रित करते |
4 | maven-dependency-plugin | अवलंबित्व लायब्ररी कॉपी करण्याची प्रक्रिया नियंत्रित करते |
५ | maven-जार-प्लगइन | अंतिम जार फाइल तयार करण्यासाठी प्लगइन |
6 | maven युद्ध प्लगइन | अंतिम युद्ध फाइल तयार करण्यासाठी प्लगइन |
७ | maven-surefire-plugin | चाचणी धावांचे व्यवस्थापन करते |
8 | buildnumber-maven-plugin | बिल्ड नंबर व्युत्पन्न करते |
प्रत्येक प्लगइन त्याच्या स्वत: च्या मार्गाने मनोरंजक आहे, परंतु आम्हाला त्या सर्वांचे विश्लेषण करावे लागेल. चला मुख्य गोष्टीपासून सुरुवात करूया - संकलन व्यवस्थापन प्लगइन.
1.2 संकलन प्लगइन maven-compiler-plugin
सर्वात लोकप्रिय प्लगइन जे तुम्हाला कंपाइलरची आवृत्ती नियंत्रित करण्यास अनुमती देते आणि जवळजवळ सर्व प्रकल्पांमध्ये वापरले जाते maven-compiler-plugin
. यात डीफॉल्ट सेटिंग्ज आहेत, परंतु जवळजवळ प्रत्येक प्रोजेक्टमध्ये ते पुन्हा सेट करणे आवश्यक आहे.
सर्वात सोप्या आवृत्तीमध्ये, प्लग-इनमध्ये, आपल्याला जावा स्त्रोत कोडची आवृत्ती आणि जावा मशीनची आवृत्ती निर्दिष्ट करणे आवश्यक आहे ज्या अंतर्गत असेंब्ली केली जाते:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.2</version>
<configuration>
<source>1.11</source>
<target>1.13</target>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
वरील उदाहरणामध्ये, आम्ही तीन Java कंपाइलर पर्याय सेट केले आहेत: source
, target
आणि encoding
.
पॅरामीटर source
आम्हाला आमच्या स्त्रोतांसाठी Java आवृत्ती सेट करण्यास अनुमती देते. पॅरामीटर target
ही Java मशीनची आवृत्ती आहे ज्या अंतर्गत तुम्हाला वर्ग संकलित करायचे आहेत. जर कोणताही कोड किंवा Java मशीन आवृत्ती निर्दिष्ट केली नसेल, तर डीफॉल्ट 1.3 आहे
शेवटी, पॅरामीटर encoding
तुम्हाला Java फाइल्सचे एन्कोडिंग निर्दिष्ट करण्याची परवानगी देतो. आम्ही सूचित केले UTF-8
. आता जवळजवळ सर्व स्रोत मध्ये संग्रहित आहेत UTF-8
. परंतु हे पॅरामीटर निर्दिष्ट केलेले नसल्यास, ऑपरेटिंग सिस्टमचे वर्तमान एन्कोडिंग निवडले जाईल. विंडोजसाठी, हे एन्कोडिंग आहे Windows-1251
.
अशी प्रकरणे देखील आहेत जेव्हा बिल्ड कॉम्प्यूटरमध्ये Java च्या अनेक आवृत्त्या स्थापित केल्या जातात: भिन्न मॉड्यूल आणि/किंवा भिन्न प्रकल्प तयार करण्यासाठी. या प्रकरणात, JAVA_HOME
त्यापैकी फक्त एकाचा मार्ग व्हेरिएबलमध्ये निर्दिष्ट केला जाऊ शकतो.
याव्यतिरिक्त, जावा मशीनची विविध अंमलबजावणी आहेत: OpenJDK, OracleJDK, Amazon JDK. आणि प्रकल्प जितका मोठा असेल तितकी त्याची रचना अधिक जटिल असेल. परंतु तुम्ही टॅग वापरून प्लगइनसाठी javac कंपाइलरचा मार्ग स्पष्टपणे सेट करू शकता.
प्लगइनची maven-compiler-plugin
दोन उद्दिष्टे आहेत:
compiler:compile
- स्रोतांचे संकलन, संकलित टप्प्याशी संबंधित डीफॉल्टनुसारcompiler:testCompile
- चाचण्यांचे संकलन, डीफॉल्टनुसार ते चाचणी-संकलित टप्प्याशी संबंधित आहे.
तुम्ही कमांड लाइनवर javac कंपाइलरला पाठवल्या जाणार्या वितर्कांची सूची देखील निर्दिष्ट करू शकता:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.2</version>
<configuration>
<compilerArgs>
<arg>-verbose</arg>
<arg>-Xlint:all,-options,-path<arg>
</compilerArgs>
</configuration>
</plugin>
1.3 जार फाइल maven-jar-plugin तयार करण्यासाठी प्लगइन
जर तुम्हाला मावेनसह तुमची स्वतःची जार लायब्ररी तयार करायची असेल, तर तुम्हाला maven-jar-plugin ची आवश्यकता असेल. हे प्लगइन अनेक उपयुक्त गोष्टी करते.
अशा प्लगइनचे उदाहरणः
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<includes>
<include>**/properties/*</include>
</includes>
<archive>
<manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
</plugin>
प्रथम, कोणत्या फाइल्स लायब्ररीमध्ये जातील आणि कोणत्या नाहीत हे निर्दिष्ट करण्यासाठी याचा वापर केला जाऊ शकतो. <include>
विभागातील टॅग वापरून , <includes>
तुम्ही लायब्ररीमध्ये ज्यांची सामग्री जोडणे आवश्यक आहे अशा निर्देशिकांची सूची निर्दिष्ट करू शकता .
दुसरे म्हणजे, प्रत्येक जारमध्ये मॅनिफेस्ट ( MANIFEST.MF फाइल ) असणे आवश्यक आहे. प्लगइन स्वतःच ते लायब्ररीमध्ये योग्य ठिकाणी ठेवेल, तुम्हाला तो कोणता मार्ग घ्यायचा हे निर्दिष्ट करणे आवश्यक आहे. यासाठी टॅग वापरला जातो <manifestFile>
.
शेवटी, प्लगइन स्वतःच मॅनिफेस्ट तयार करू शकते. हे करण्यासाठी, टॅगऐवजी, <manifestFile>
तुम्हाला टॅग जोडणे आवश्यक आहे <manifest>
आणि त्यात भविष्यातील मॅनिफेस्टसाठी डेटा निर्दिष्ट करणे आवश्यक आहे. उदाहरण:
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
<mainClass>com.codegym.MainApplication</mainClass>
</manifest>
</archive>
</configuration>
<addClasspath>
मॅनिफेस्टमध्ये जोडायचे की नाही हे टॅग निर्दिष्ट करते CLASSPATH
.
टॅग <classpathPrefix>
तुम्हाला प्रत्येक संसाधनापूर्वी उपसर्ग (उदाहरण lib मध्ये) जोडण्याची परवानगी देतो. मध्ये उपसर्ग निर्दिष्ट केल्याने <classpathPrefix>
तुम्हाला वेगळ्या फोल्डरमध्ये अवलंबित्व ठेवण्याची परवानगी मिळते.
होय, तुम्ही लायब्ररी दुसऱ्या लायब्ररीमध्ये ठेवू शकता. आणि जेव्हा तुम्हाला जार लायब्ररीमध्ये असलेल्या जार लायब्ररीमध्ये कुठेतरी प्रॉपर्टी फाइलकडे जाण्याची आवश्यकता असते तेव्हा अनेक आश्चर्ये तुमची वाट पाहत असतात.
शेवटी, टॅग <mainClass>
मुख्य एक्झिक्युटेबल क्लासकडे निर्देश करतो. “ मुख्य एक्झिक्युटेबल क्लास काय आहे? ", - तू विचार. आणि गोष्ट अशी आहे की जावा मशीन एक प्रोग्राम चालवू शकते जो केवळ जावा क्लासद्वारेच नव्हे तर जार फाइलद्वारे देखील निर्दिष्ट केला जातो. आणि या प्रकरणात मुख्य प्रारंभिक वर्ग आवश्यक आहे.
1.4 बिल्ड नंबर जनरेशन प्लगइन buildnumber-maven-plugin
बर्याचदा, जार लायब्ररी आणि युद्ध फायलींमध्ये प्रकल्पाचे नाव आणि त्याची आवृत्ती तसेच असेंब्लीची आवृत्ती समाविष्ट असते. हे केवळ अवलंबित्व व्यवस्थापित करण्यासाठीच उपयुक्त नाही, परंतु ते चाचणी देखील सुलभ करते: हे स्पष्ट आहे की लायब्ररीच्या कोणत्या आवृत्तीमध्ये त्रुटी निश्चित केली गेली आहे आणि ती जोडली गेली आहे.
बर्याचदा, हे कार्य अशा प्रकारे सोडवले जाते - ते एक विशेष फाइल तयार करतात application.properties
ज्यामध्ये सर्व आवश्यक माहिती असते आणि ती असेंब्लीमध्ये समाविष्ट असते. तुम्ही बिल्ड स्क्रिप्ट देखील कॉन्फिगर करू शकता जेणेकरुन या फाइलमधील डेटा MANIFEST.MF
इ. वर स्थलांतरित होईल.
पण सर्वात मनोरंजक गोष्ट म्हणजे मावेनकडे एक विशेष प्लगइन आहे जे अशी application.properties फाइल तयार करू शकते. हे करण्यासाठी, आपल्याला अशी फाइल तयार करण्याची आणि ती विशेष डेटा टेम्पलेट्ससह भरण्याची आवश्यकता आहे. उदाहरण:
# application.properties
app.name=${pom.name}
app.version=${pom.version}
app.build=${buildNumber}
सर्व तीन पॅरामीटर्सची मूल्ये बिल्ड स्टेजवर बदलली जातील.
पॅरामीटर्स pom.name
आणि pom.version
थेट कडून घेतले जातील pom.xml
. आणि Maven मध्ये एक अद्वितीय बिल्ड नंबर व्युत्पन्न करण्यासाठी, एक विशेष प्लगइन आहे - buildnumber-maven-plugin
. खालील उदाहरण पहा:
<packaging>war</packaging>
<version>1.0</version>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>buildnumber-maven-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
</execution>
</executions>
<configuration>
<revisionOnScmFailure>true</revisionOnScmFailure>
<format>{0}-{1,date,yyyyMMdd}</format>
<items>
<item>${project.version}</item>
<item>timestamp</item>
</items>
</configuration>
</plugin>
</plugins>
वरील उदाहरणात तीन महत्त्वाच्या गोष्टी घडतात. प्रथम, प्लगइन स्वतः असेंबली आवृत्ती सेट करण्यासाठी निर्दिष्ट केले आहे . दुसरे म्हणजे, हे निर्दिष्ट केले आहे की ते प्रमाणीकरण टप्प्यात (अगदी पहिल्या टप्प्यात) चालेल आणि एक बिल्ड नंबर तयार करेल - ${buildNumber}
.
आणि तिसरे म्हणजे, या असेंब्ली नंबरचे स्वरूप सूचित केले आहे, जे अनेक भागांमधून एकत्र चिकटलेले आहे . ही प्रकल्पाची आवृत्ती project.version
आणि टेम्पलेटद्वारे दिलेली वर्तमान वेळ आहे. टेम्पलेट स्वरूप Java वर्गाद्वारे निर्दिष्ट केले आहे MessageFormat
.
GO TO FULL VERSION