मैवेन मल्टी-मॉड्यूल प्रोजेक्ट को पुन: स्थापित कैसे करें?

Question

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

एक परियोजना पदानुक्रम के रूप में, सभी मॉड्यूल "फ्लैट" संग्रहित होते हैं; यानी: सबकुछ एक ही स्तर पर है। मेरे पास एक अभिभावक पोम है, और सभी मॉड्यूल माता-पिता पर निर्भर करते हैं। हालांकि, माता-पिता मेरे सभी अन्य मॉड्यूल के समान स्तर पर हैं।

पूर्व:

c:\dev\MyEarProject 
+ parent-pom 
    - pom.xml 
+ module1 
    - pom.xml (depends on parent-pom) 
    - src 
    - main 
    -  ... 
+ module2 
    - pom.xml (depends on parent-pom) 
    - src 
    - main 
    -  ... 
+ module3 
    - pom.xml (depends on parent-pom) 
    - src 
    - main 
    -  ... 

माता पिता पोम सभी परियोजना है, साथ ही विभिन्न submodules भर में इस्तेमाल विरूपण साक्ष्य संस्करण संख्याओं के लिए गुण का एक समूह बनाने के लिए आवश्यक मॉड्यूल परिभाषित करता है:

<modules> 
    <module>../module1</module> 
    <module>../module2</module> 
    <module>../module3</module> 
</modules> 

<properties> 
    <org.springframework.version>3.0.5.RELEASE</org.springframework.version> 
    <slf4j.version>1.6.4</slf4j.version> 
    <repositoryAddress>${snapshots.repo.url}</repositoryAddress> 
    <my.hibernate-module.dao.impl>1.2.3</my.hibernate-module.dao.impl> 
    <my.hibernate-module.dao.api>1.2.3</my.hibernate-module.dao.api> 
</properties> 

प्रत्येक मॉड्यूल का पोम बदले में, पोम के आर्टिफैक्ट नंबर के माध्यम से पेरेंट पोम पर निर्भर करता है:

<parent> 
    <groupId>com.cws.cs.lendingsimulationservice</groupId> 
    <artifactId>parent-pom</artifactId> 
    <version>1.0.6</version> 
</parent> 

चीजों को और भी भ्रमित करने के लिए, वास्तविक आर्टिफैक्ट नाम मॉड्यूल पथ से मेल खा सकता है, या मॉड्यूल के आधार पर नहीं हो सकता है। उदाहरण के लिए, मॉड्यूल 1 पथ c:\dev\MyEarProject\module1 में स्थित हो सकता है लेकिन आर्टिफैक्ट नाम hibernate-module है। हालांकि, जिस तरह से इसे आरटीसी में संग्रहीत किया जाता है, निर्देशिका को चेक-आउट होने पर module1 कहा जाता है।

सब कुछ बनाने का सबसे आसान तरीका, निश्चित रूप से c:\dev\MyEarProject\parent-pom\ में जाना है और mvn clean deploy चलाएं। यह ठीक काम करता है जब SNAPSHOT मोड में SNAPSHOT रेपो एक ही आर्टिफैक्ट संस्करण की कई तैनाती की अनुमति देता है। लेकिन रिलीज मोड में, यह विफल रहता है।

यह संरचना मेरे लिए 2 समस्याएं पैदा कर रही है।

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

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

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

Answer 1

पहली चीज़ जो मैं वास्तव में अनुशंसा करता हूं वह परियोजना फ़ोल्डर्स को पुन: स्थापित करना है ... जिसका अर्थ है कि प्रोजेक्ट फ़ोल्डर संरचना का प्रतिनिधित्व करता है जिसका अर्थ है संरचना को फ़्लैट करें।

+-- parent-pom (pom.xml) 
     +--- module1 (pom.xml) 
     +--- module2 (pom.xml) 
     +--- module3 (pom.xml) 

कि मॉड्यूल अनुभाग आपके माता-पिता इस तरह सरल बनाया जाएगा के परिणामस्वरूप:

<modules> 
    <module>module1</module> 
    <module>module2</module> 
    <module>module3</module> 
</modules> 

इसके अलावा अपने मॉड्यूल में माता-पिता प्रविष्टियों इस तरह के रूप में अच्छी तरह से सरल किया जा सकता:

<parent> 
    <groupId>com.cws.cs.lendingsimulationservice</groupId> 
    <artifactId>parent-pom</artifactId> 
    <version>1.0.6</version> 
</parent> 

... जो मुझे अगले बिंदु पर लाता है:

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

साथ अपनी समस्याओं के अधिकांश भाग के कारण हम इस समस्या यह इस जो मैं सिफारिश नहीं कर सकते हैं की तरह लग रहे करने के लिए है ठीक है तो है:

<parent> 
    <groupId>com.cws.cs.lendingsimulationservice</groupId> 
    <artifactId>parent-pom</artifactId> 
    <version>1.0.6</version> 
    <relativePath>../parent-pom/pom.xml</relativePath> 
</parent> 

एक दूसरी बात जो मैं निरीक्षण करें कि आप SNAPTSHOT का उपयोग नहीं करते हैं जिसे रिलीज चरण के दौरान रिलीज प्लगइन द्वारा प्रतिस्थापित किया जाएगा। और वह यह स्वचालित रूप से उचित माता-पिता आदि

आदर्श मामले में अपने मॉड्यूल इस तरह दिखना चाहिए में सभी संस्करणों के लिए बदल जाएगा के संबंध में:

<parent> 
    <groupId>com.cws.cs.lendingsimulationservice</groupId> 
    <artifactId>parent-pom</artifactId> 
    <version>1.0.6</version> 
</parent> 

<artifactId>module-1</artifactId> 
<!-- No Version or groupId --> 

कारण सभी मॉड्यूल संस्करण प्राप्त कर लेंगे और groupId अपने अभिभावकों से । कभी-कभी यह मॉड्यूल groupId को बदलने के लिए उपयोगी या आवश्यक है लेकिन यह एक अपवाद है।

जिस चीज पर मैं पढ़ता हूं, वह माता-पिता के अलग-अलग संस्करण के बारे में है। यह केवल समझ में नहीं आता है, क्योंकि यह उनके मॉड्यूल के माता-पिता हैं, इसलिए इसे उसी संरचना में और निश्चित रूप से वही वीसीएस में रखें।

आप कुछ विन्यास/plugins संस्करण बनाना चाहते हैं, निर्भरता जो अन्य परियोजनाओं के लिए रूप में अच्छी तरह से इस्तेमाल किया जाना चाहिए एक अलग कॉर्पोरेट pom.xml जो एक अलग परियोजना है और अलग से आदि जारी किया जाएगा

के बाद आप समाप्त कर आपकी संरचना में परिवर्तन आप आसानी से पेरेंट-पोम निर्देशिका में जा सकते हैं और उस फ़ोल्डर से mvn clean package या mvn release:prepare release:perform कर सकते हैं और सब कुछ आसान होगा।

Answer 2

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

mvn versions:set 

http://mojo.codehaus.org/versions-maven-plugin/

mvn release:prepare release:perform 

http://maven.apache.org/plugins/maven-release-plugin/

आपका भंडार प्रबंधक भी किसी मौजूदा संस्करण को अधिलेखित करने की अनुमति दे सकता है, लेकिन यह सिर्फ एक नया संस्करण जारी करने के लिए बेहतर व्यवहार है।

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

Answer 3

आप विरोधाभासी आवश्यकताओं को पेश कर रहे हैं। आप अपनी परियोजना को पुन: व्यवस्थित करना चाहते हैं लेकिन चीजों को चारों ओर स्थानांतरित नहीं कर सकते हैं। आप अपनी तैनाती को सरल बनाना चाहते हैं और चक्र छोड़ना चाहते हैं लेकिन एक संस्करण का उपयोग नहीं करना चाहते हैं।

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

आपकी परियोजना के साथ शुभकामनाएँ।