मावेन पैरेंट पोम बनाम मॉड्यूल पोम

Question

मल्टीप्रोजेक्ट बिल्ड में पैरेंट पॉम को स्ट्रक्चर करने के कई तरीके प्रतीत होते हैं और मुझे आश्चर्य होता है कि किसी को भी इस बात पर कोई विचार था कि प्रत्येक तरीके से क्या फायदे / कमियां हैं।

पैरेंट पोम होने का सबसे सरल तरीका इसे एक प्रोजेक्ट के मूल में रखा जाएगा

myproject/
  myproject-core/
  myproject-api/
  myproject-app/
  pom.xml

जहाँ pom.xml मूल परियोजना दोनों के साथ-साथ -कोर-पेपी और -app मॉड्यूल का वर्णन करता है

अगली विधि माता-पिता को अपने स्वयं के उपनिर्देशिका में अलग करने के लिए है

myproject/
  mypoject-parent/
    pom.xml
  myproject-core/
  myproject-api/
  myproject-app/

जहां मूल पोम में अभी भी मॉड्यूल शामिल हैं, लेकिन वे सापेक्ष हैं, उदा ../myproject-core

अंत में, वहाँ विकल्प है जहाँ मॉड्यूल की परिभाषा और अभिभावक को अलग किया जाता है

myproject/
  mypoject-parent/
    pom.xml
  myproject-core/
  myproject-api/
  myproject-app/
  pom.xml

जहां मूल पोम में कोई "साझा" कॉन्फ़िगरेशन (निर्भरता प्रबंधन, गुण आदि) होते हैं और myproject / pom.xml में मॉड्यूल की सूची होती है।

इरादा बड़े पैमाने पर निर्माण के लिए स्केलेबल होना चाहिए ताकि बड़ी संख्या में परियोजनाओं और कलाकृतियों के लिए स्केलेबल होना चाहिए।

कुछ बोनस प्रश्न:

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

संपादित करें: प्रत्येक उप परियोजनाओं में अपना स्वयं का pom.xml है, मैंने इसे रखना जारी रखा है।

Comments

क्या मॉड्यूल में से प्रत्येक का अपना पोम भी है? मेरी परियोजना में एक माता-पिता पोम है, लेकिन प्रत्येक मॉड्यूल में एक पोम भी है। (शायद आप यू का वर्णन करने का चौथा तरीका है)

— harschware

आह, हाँ, मैं संपादित करूँगा और अपडेट करूँगा। प्रत्येक सबमॉड्यूल का अपना पोम भी होता है।

— जेमी मैक्रिंडल

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

— जेमी मैक्रिंडल 18

Answer 1

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

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

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
`-- projectA
    |-- branches
    |-- tags
    `-- trunk
        |-- module1
        |   `-- pom.xml
        |-- moduleN
        |   `-- pom.xml
        `-- pom.xml

यह चेकआउट को थोड़ा दर्दनाक बनाता है और इससे निपटने का एक सामान्य तरीका है svn:externals। उदाहरण के लिए, एक trunksनिर्देशिका जोड़ें :

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
|-- projectA
|   |-- branches
|   |-- tags
|   `-- trunk
|       |-- module1
|       |   `-- pom.xml
|       |-- moduleN
|       |   `-- pom.xml
|       `-- pom.xml
`-- trunks

निम्नलिखित बाह्य परिभाषा के साथ:

parent-pom http://host/svn/parent-pom/trunk
projectA http://host/svn/projectA/trunk

trunksतब निम्न स्थानीय संरचना (पैटर्न # 2) में एक चेकआउट होगा:

root/
  parent-pom/
    pom.xml
  projectA/

वैकल्पिक रूप से, आप निर्देशिका pom.xmlमें भी जोड़ सकते हैं trunks:

root
|-- parent-pom
|   |-- branches
|   |-- tags
|   `-- trunk
|       `-- pom.xml
|-- projectA
|   |-- branches
|   |-- tags
|   `-- trunk
|       |-- module1
|       |   `-- pom.xml
|       |-- moduleN
|       |   `-- pom.xml
|       `-- pom.xml
`-- trunks
    `-- pom.xml

यह pom.xmlएक तरह का "नकली" पोम है: यह कभी रिलीज़ नहीं होता है, इसमें कोई वास्तविक संस्करण नहीं होता है क्योंकि यह फ़ाइल कभी रिलीज़ नहीं होती है, इसमें केवल मॉड्यूल की सूची होती है। इस फ़ाइल के साथ, इस संरचना में एक चेकआउट होगा (पैटर्न # 3):

root/
  parent-pom/
    pom.xml
  projectA/
  pom.xml

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

यदि उत्तर नहीं है (प्रारंभिक प्रश्न पर वापस), तो मुझे लगता है कि आप पैटर्न # 1 के साथ रह सकते हैं (सबसे सरल काम करें जो संभवतः काम कर सकते हैं)।

अब, बोनस प्रश्नों के बारे में:

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

ईमानदारी से, मैं नहीं जानता कि यहां एक सामान्य उत्तर कैसे नहीं दिया जाए (जैसे "उस स्तर का उपयोग करें जिस पर आपको लगता है कि यह चीजों को पारस्परिक बनाने के लिए समझ में आता है")। और वैसे भी, चाइल्ड पॉम हमेशा विरासत में मिली सेटिंग्स को ओवरराइड कर सकते हैं।

• मावेन-रिलीज़ प्लगइन, हडसन और नेक्सस कैसे आपके मल्टी-प्रोजेक्ट्स को सेट करते हैं (संभवतः एक विशाल सवाल है, यह अधिक है अगर किसी को पकड़ा गया है जब मल्टी-प्रोजेक्ट बिल्ड कैसे सेट किया गया है)?

मैं जिस सेटअप का उपयोग करता हूं वह अच्छी तरह से काम करता है, विशेष रूप से उल्लेख करने के लिए कुछ भी नहीं है।

वास्तव में, मुझे आश्चर्य है कि मावेन-रिलीज़-प्लगइन कैसे पैटर्न # 1 के साथ काम करता है (विशेषकर तब <parent>अनुभाग के साथ जब से आप रिलीज़ समय में स्नैपशॉट निर्भरता नहीं कर सकते हैं)। यह एक चिकन या अंडे की समस्या की तरह लगता है, लेकिन मुझे याद नहीं है कि यह काम करता है और यह परीक्षण करने के लिए बहुत आलसी था।

Comments

यह बहुत अच्छा है क्योंकि मैं देख सकता हूं कि यह कैसे तराजू है। Svn: बाहरी लोग मेरी चिंता का जवाब देते हैं कि यह बोझिल है।

— जेमी मैक्रिंडल

@ जैमी ग्लैड आपको यह मददगार लगता है।

— पास्कल थिवेंट

क्या आप "हैक" कार्य करने के तरीके पर विस्तार से बता सकते हैं? मुझे चड्डी परियोजना मिल गई है और अनुमान है कि आप "रिएक्टर बिल्ड के लॉन्च" के साथ -pl विकल्प को लक्षित करते हैं, लेकिन यह संरचना पर एक रिलीज करते समय एक समस्या के रूप में प्रस्तुत करता है क्योंकि यह विकल्प रूट स्तर पर बिल्ड से नहीं गुजरता है और न ही क्या मैं इसे रिलीज़-प्लगिन के <वाद /> विकल्प में रख सकता हूँ। इसलिए रिहाई: विफलताओं का प्रदर्शन करती है क्योंकि यह रूट-लेवल पोम पर काम करने की कोशिश करती है ...

— Jan

Svn: एक्सटर्नल हैक सबसे उपयोगी svn हैक है जिसे मैंने लंबे समय में देखा है। एक ही रिपॉजिटरी के भीतर प्रति-प्रोजेक्ट शाखाकरण वाली परियोजनाओं के साथ बहुत मददगार।

— kोमकरुदत

हाय पास्कल, आप संस्करण को कैसे संभालेंगे # यदि प्रोजेक्ट्स जो मॉड्यूल अनुभाग में उल्लिखित हैं, माता-पिता-पोम को इसके <अभिभावक> के रूप में उपयोग नहीं करते हैं, लेकिन कुछ अन्य-प्रोजेक्ट-पैरेंट-पोम? ऐसी परियोजनाओं की एक कलाकृतियों के लिए हमें कौन से संस्करण # मिलेंगे? stackoverflow.com/questions/25918593/…

— AKS

Answer 2

मेरे अनुभव और मावेन सर्वोत्तम प्रथाओं से "माता-पिता" के दो प्रकार हैं।

• "कंपनी" पैरेंट पोम - इस पोम में आपकी कंपनी की विशिष्ट जानकारी और कॉन्फ़िगरेशन होती है जो हर पोम को प्राप्त करती है और इसे कॉपी करने की आवश्यकता नहीं होती है। ये सुझाव हैं:

  • खजाने
  • वितरण प्रबंधन वर्गों
  • सामान्य प्लगइन्स कॉन्फ़िगरेशन (जैसे मावेन-कंपाइलर-प्लगइन स्रोत और लक्ष्य संस्करण)
  • संगठन, डेवलपर्स, आदि

  इस पैरेंट पोम को तैयार करने में सावधानी बरतने की जरूरत है, क्योंकि आपकी कंपनी के सभी पॉम इससे विरासत में मिलेंगे, इसलिए इस पोम को परिपक्व और स्थिर होना होगा (पेरेंट पोम के एक संस्करण को जारी करने से आपकी सभी कंपनी प्रोजेक्ट्स को रिलीज करने के लिए प्रभावित नहीं होना चाहिए!)

• दूसरी तरह का पेरेंट पोम एक मल्टीमॉडल पेरेंट है। मैं आपका पहला समाधान पसंद करता हूं - यह मल्टी मॉड्यूल परियोजनाओं के लिए एक डिफ़ॉल्ट मावेन सम्मेलन है, जो अक्सर वीसीएस कोड संरचना का प्रतिनिधित्व करता है

इरादा बड़े पैमाने पर निर्माण के लिए स्केलेबल होना चाहिए ताकि बड़ी संख्या में परियोजनाओं और कलाकृतियों के लिए स्केलेबल होना चाहिए।

Mutliprojects में पेड़ों की संरचना होती है - इसलिए आप मूल पोम के एक स्तर तक नीचे नहीं जाते हैं। अपनी आवश्यकताओं के लिए एक उपयुक्त प्रोजेक्ट स्ट्रेंथ खोजने की कोशिश करें - एक क्लासिक छूट है कि म्यूटिमोड्यूले प्रोजेक्ट्स को कैसे अशुभ किया जाए

distibution/
documentation/
myproject/
  myproject-core/
  myproject-api/
  myproject-app/
  pom.xml
pom.xml

कुछ बोनस प्रश्न:

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

इस कॉन्फ़िगरेशन को समझदारी से एक "कंपनी" पैरेंट पोम और प्रोजेक्ट पैरेंट पोम (एस) में विभाजित किया जाना है। आपके द्वारा प्रोजेक्ट की गई सभी चीजें "कंपनी" के माता-पिता के पास जाती हैं और यह वर्तमान प्रोजेक्ट से संबंधित होती हैं।

• मावेन-रिलीज़ प्लगइन, हडसन और नेक्सस कैसे आपके मल्टी-प्रोजेक्ट्स को सेट करते हैं (संभवतः एक विशाल सवाल है, यह अधिक है अगर किसी को पकड़ा गया है जब मल्टी-प्रोजेक्ट बिल्ड कैसे सेट किया गया है)?

कंपनी पैरेंट पोम को पहले जारी किया जाना है। मल्टीप्रोजेक्ट के लिए मानक नियम लागू होते हैं। CI सर्वर को प्रोजेक्ट को सही ढंग से बनाने के लिए सभी को जानना आवश्यक है।

Comments

ताकि दो प्रकार के मूल प्रोजेक्ट / पोम्स हों। एक के बिना <मॉड्यूल> घोषणा। यह वह है जो इनहेरिटेंस के लिए उपयोग किया जाता है। और एक मूल परियोजना <मल्टीमॉडल> ​​घोषणा के साथ। यह वह है जिसे सबमॉड्यूल से विरासत में नहीं मिला है, यह सिर्फ होल्ड प्रोजेक्ट के निर्माण का प्रबंधन करना है। क्या मैं सही हू ?

— 15

Answer 3

1. एक स्वतंत्र माता-पिता कॉन्फ़िगरेशन और विकल्पों को साझा करने के लिए सबसे अच्छा अभ्यास है, अन्यथा अनप्लग किए गए घटक। अपाचे में कानूनी नोटिस और कुछ सामान्य पैकेजिंग विकल्पों को साझा करने के लिए एक मूल पोम परियोजना है।

2. यदि आपकी शीर्ष-स्तरीय परियोजना में वास्तविक काम है, जैसे कि javadoc को एकत्र करना या किसी रिलीज़ को पैकेजिंग करना, तो आपके पास उस कार्य को करने के लिए आवश्यक सेटिंग्स और आपके द्वारा माता-पिता के माध्यम से साझा करना चाहते सेटिंग्स के बीच संघर्ष होगा। एक पैरेंट-ओनली प्रोजेक्ट इससे बचता है।

3. एक सामान्य पैटर्न (पल के लिए # 1 को अनदेखा करना) एक माता-पिता के रूप में प्रोजेक्ट-के-कोड का उपयोग मूल परियोजना है, और क्या यह एक माता-पिता के रूप में शीर्ष-स्तर का उपयोग करता है। यह मुख्य चीजों को सभी द्वारा साझा करने की अनुमति देता है, लेकिन # 2 में वर्णित समस्या से बचा जाता है।

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

5. Apache CXF # 2 में एक उदाहरण है।

Comments

मैंने ibilio पर एक नज़र डाली है और बहुत सारी परियोजनाएं "स्वतंत्र" मूल पॉम को पसंद करती हैं। हाइबरनेट, एक्टिवएमक्यू, जेट्टी, एक्सस्ट्रीम आदि जो यह बताता है कि यह डिफेक्टो तंत्र है।

— जेमी मैक्रिंडल

स्वतंत्र माता-पिता का एक और नकारात्मक पहलू यह है कि मावेन रिलीज प्लगइन माता-पिता को एक संस्करण में पिन किए जाने से पहले एक रिलीज करने के लिए चाहते हैं प्रतीत होता है। शायद बहुत ज्यादा समस्या नहीं है क्योंकि माता-पिता को बहुत ज्यादा नहीं बदलना चाहिए।

— जेमी मैक्रिंडले

Answer 4

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

यह एक समस्या नहीं है यदि आप केवल सेंट्रल से प्लगइन्स का उपयोग करते हैं, हालांकि, यदि आप प्लगइन का उपयोग करके प्लगइन चलाते हैं तो यह विफल हो जाएगा: आपके आंतरिक भंडार से लक्ष्य प्रारूप। उदाहरण के लिए, आप लक्ष्य प्रदान करने foo-maven-pluginके GroupId के साथ हो सकते हैं । यदि आप इसे कमांड रूट का उपयोग करके प्रोजेक्ट रूट से चलाने का प्रयास करते हैं , तो यह एग्रीगेट मॉड्यूल ( संगतता नोट देखें ) पर चलने में विफल हो जाएगा ।org.examplegenerate-foomvn org.example:foo-maven-plugin:generate-foo

कई समाधान संभव हैं:

1. मावेन सेंट्रल (हमेशा संभव नहीं) के लिए प्लगइन तैनात करें।
2. अपने सभी POMs ( DRY को तोड़ता है) में रिपॉजिटरी अनुभाग निर्दिष्ट करें सिद्धांत को है) ।
3. इस आंतरिक रिपॉजिटरी को settings.xml (या तो स्थानीय सेटिंग्स में ~ / .m2 / settings.xml पर या वैश्विक सेटिंग्स में /conf/settings.xml पर) कॉन्फ़िगर किया गया है। उन सेटिंग्स के बिना बिल्ड फेल कर देगा। xml (बड़ी इन-हाउस परियोजनाओं के लिए ठीक हो सकता है जिन्हें कंपनी के बाहर निर्मित नहीं किया जाना चाहिए)।
4. अपने समग्र POMs में रिपॉजिटरी सेटिंग्स वाले पैरेंट का उपयोग करें (बहुत अधिक पैरेंट POMs हो सकता है?)।