मैवेन प्रोजेक्ट के पथ में जहां मुझे कॉन्फ़िगरेशन फ़ाइलों को रखा जाना चाहिए जिन्हें संसाधन नहीं माना जाता है

Question

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

मैं इसे देख यह डिफ़ॉल्ट एक्सएमएल के 2 संभावित स्थानों देखते हैं:

1. src/main/resources/conf/default.xml
2. src/main/conf/default.xml

दोनों समाधान की मांग विशेष पोम कार्रवाई:

• में समाधान 1, मुझे बी के दौरान फ़ोल्डर को लक्षित करने के लिए ऑटो कॉपी मिलती है उल्ड जिसका मतलब है कि यह परीक्षण में उपलब्ध है लेकिन मैं इसे उत्पादित जार में भी प्राप्त करता हूं जिसे मैं नहीं चाहता हूं।

• समाधान 2 में, मुझे जार मिलता है क्योंकि मुझे यह चाहिए (एक्सएमएल से मुक्त) लेकिन मुझे परीक्षण के लिए उपलब्ध होने के लिए मैन्युअल रूप से एक्सएमएल को लक्षित फ़ोल्डर में कॉपी करना होगा। (मैं टेस्ट क्लासपाथ में src के उपफोल्डर जोड़ना नहीं चाहता हूं। मुझे लगता है कि यह खराब अभ्यास है)।

प्रश्न: दोनों का सबसे अच्छा समाधान क्या है?
- यदि सही 2 है, तो फ़ोल्डर को लक्षित करने के लिए इसे कॉपी करने का सबसे अच्छा तरीका क्या है?
- क्या कोई अन्य समाधान बेहतर है और उन दोनों की तुलना में अधिक आम है?

(मैंने Where should I put application configuration files for a Maven project? भी पढ़ा है, लेकिन मैं "कॉन्फ़्रेंस पर सम्मेलन" बिंदु से सबसे "सही समाधान" जानना चाहता हूं और यह लिंक कुछ कॉन्फ़िगरेशन प्रकार समाधान प्रदान करता है लेकिन कोई सम्मेलन उन्मुख नहीं है। शायद वहां नहीं है एक लेकिन मैं वैसे भी पूछता हूं। इसके अलावा समाधानों में एंट्रुन प्लगइन और ऐपएस्सेबलर प्लगइन शामिल है और मुझे आश्चर्य है कि मैं इसे बाहर कर सकता हूं।)

Answer 1

सवाल यह है कि दोनों का सबसे अच्छा समाधान क्या है? यदि सही 2 है, तो फ़ोल्डर को लक्षित करने के लिए इसे कॉपी करने का सबसे अच्छा तरीका क्या है? क्या कोई अन्य समाधान उन दोनों की तुलना में बेहतर और अधिक आम है?

किसी भी तरह एक संसाधन के रूप में माना जा करने के लिए जब से तुम उस फ़ाइल target/classes फ़ोल्डर में कॉपी किया जा करना चाहते हैं, यह है (ताकि या तो src/main/resources के तहत में डाल या src/main/conf संसाधन निर्देशिका के रूप में घोषित)।और अगर आप नहीं है यह अंतिम जार में चाहते हैं, उसे बहिष्कृत Maven JAR Plugin कॉन्फ़िगर करें:

<project> 
    ... 
    <build> 
    <plugins> 
     ... 
     <plugin> 
     <groupId>org.apache.maven.plugins</groupId> 
     <artifactId>maven-jar-plugin</artifactId> 
     <version>2.3.1</version> 
     <configuration> 
      <excludes> 
      <exclude>**/conf/*</exclude> 
      </excludes> 
     </configuration> 
     </plugin> 
     ... 
    </plugins> 
    </build> 
    ... 
</project> 

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

मेरे डिफ़ॉल्ट/अनुभाग दोनों src/मुख्य/संसाधनों और src/मुख्य/conf शामिल हैं:

Answer 2

आप इसे src/test/conf/default.xml में रख सकते हैं। आपके testclasses इसे पा सकते हैं, लेकिन यह मानक विधि का उपयोग करके पैक नहीं किया जाएगा।

अतिरिक्त असेंबली के साथ आप इसे वहां से पैकेज कर सकते हैं। वह कदम हमेशा जरूरी है।

एक अलग समाधान एक अलग मेवेन मॉड्यूल बनाने और इसे/src/main/संसाधन/conf/... में रखकर एक अलग समाधान हो सकता है। फिर इस जार को एक परीक्षण निर्भरता बनाएं। आपको कोई विशेष प्लगइन कॉन्फ़िगरेशन करने की आवश्यकता नहीं है, लेकिन मुझे लगता है कि यह एक फ़ाइल के लिए अधिक है।

Answer 3

मेरे समाधान दो प्रोफाइल उपयोग करने के लिए किया गया था। मैं इसे अपनी विकास प्रोफ़ाइल कहता हूं, जो एक अंतर्निहित प्रोफ़ाइल है।

मेरी पैकेजिंग प्रोफ़ाइल एक स्पष्ट प्रोफ़ाइल है जो अनुभाग के तहत परिभाषित की गई है। नीचे/मैंने केवल src/main/संसाधनों का उल्लेख किया है। जब मैं अपनी पैकेजिंग स्क्रिप्ट चला रहा हूं (वर्तमान में हमारे पास हमारे WAR से आरपीएम बनाने के बाद से यह मैवेन के लिए बाहरी है), मैं अपने पैकेजिंग प्रोफाइल को सक्रिय करने के लिए 'mvn install -Drpm' चला रहा हूं (आरपीएम पैकेजिंग के लिए आईडी है प्रोफ़ाइल।

यदि यह पर्याप्त स्पष्ट नहीं था, और प्रश्न पूछने के लिए स्वतंत्र महसूस।