गुण फ़ाइल के लिए जावा पथ निर्दिष्ट करना

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

इकाई परीक्षण स्थित हैं पेड़ में (, परियोजना पथ के सापेक्ष निश्चित रूप से)

src/test/java/com (...)

उन परीक्षणों के लिए संसाधन फ़ाइलों

src/test/resources(...)

और अंत में कर रहे हैं, गुण फ़ाइल है, जो संसाधन फ़ाइल


@ContextConfiguration(locations = { "classpath:com/initrode/quartz/SyncManagerJobTest-context.xml"})

: पढ़ना चाहिए, अब निर्देशिका

src/main/filters

में है, मैं एक JUnit वर्ग जहां मैं इस तरह विन्यास फाइल स्थान को निर्दिष्ट किया है

विन्यास फाइल SyncManagerJobTest-context.xml में एक लाइन


<context:property-placeholder location="/src/main/filters/deploy.local.properties"/>

इस गुण में परिणाम फ़ाइल निर्देशिका से पढ़ने के लिए नहीं है। मैं जो पढ़ना चाहता हूं वह गुण फ़ाइल है, जो src/main/filter के अंतर्गत स्थित है। मैंने ऊपर की निर्देशिका को पार करने के लिए ../../ का उपयोग करने का प्रयास किया, लेकिन इससे मदद नहीं मिली। क्लासपाथ का उपयोग करना: या तो काम नहीं किया। मैं "फ़ाइल:" के साथ एक पूर्ण पथ का उपयोग कर सकता हूं, लेकिन इस परियोजना में प्रत्येक डेवलपर को कॉन्फ़िगरेशन को संशोधित करने की आवश्यकता होगी, जो कि अच्छा नहीं है।

संक्षेप में, सवाल यह है: मैं src/test/resource/में प्रसंस्करण फ़ाइल को src/main/filter में गुण फ़ाइल को पढ़ने के लिए कैसे मजबूर कर सकता हूं?

और संबंधित बोनस प्रश्न: जावा वातावरण में फ़ाइलों को संभालने पर, "फ़ाइल:" और "कक्षापथ" से अन्य संशोधक हैं?

स्रोत

2009-09-29 simon

यदि आप संसाधन स्थान के रूप में src/main/filters निर्दिष्ट करते हैं, तो मैवेन संसाधनों को target/classes पर ले जायेगा, और बिल्ड के दौरान कक्षाओं को उसी स्थान पर संकलित भी करेगा। तब आपके पास एक ही रूट होने के साथ निपटने के लिए एक सापेक्ष पथ नहीं है। यदि आप ऐसा कुछ नहीं करते हैं, तो आपकी फ़िल्टर निर्देशिका को बिल्ड में शामिल नहीं किया जाएगा।

अपडेट: बेशक आपका टेस्ट कोड लक्ष्य/परीक्षण-वर्गों के लिए आउटपुट है, इसलिए परीक्षण को सरल बनाने के लिए, आप निर्दिष्ट कर सकते हैं कि src/main/filters को प्रक्रिया-परीक्षण-संसाधन चरण के दौरान target/test-classes पर कॉपी किया गया है। मैंने उस व्यवहार को दिखाने के लिए उदाहरण को संशोधित किया है।

यदि आपने पहले से ऐसा नहीं किया है, तो आप फ़िल्टर फ़ोल्डर को संसाधन स्थान के रूप में जोड़ने के लिए build-helper-maven-plugin का उपयोग कर सकते हैं।

ऐसा करने के लिए विन्यास इस तरह दिखता है:

<plugin> 
    <groupId>org.codehaus.mojo</groupId> 
    <artifactId>build-helper-maven-plugin</artifactId> 
    <version>1.3</version> 
    <executions> 
    <execution> 
     <id>add-resource</id> 
     <phase>process-test-sources</phase> 
     <goals> 
     <goal>add-test-resource</goal> 
     </goals> 
     <configuration> 
     <resources> 
      <resource> 
      <directory>scr/main/filters</directory> 
      </resource> 
     </resources> 
     </configuration> 
    </execution> 
    </executions> 
</plugin>

स्रोत

2009-09-29 09:34:36

मेरे लिए

, यह डाल करने के लिए आप के रूप में इस फ़ाइल का उपयोग करने की योजना नहीं है, तो एक गुण src/main/filters में दाखिल थोड़ा अजीब लगता है ... एक फिल्टर। यदि यह फ़ाइल मानक परीक्षण संसाधन के रूप में उपयोग की जाती है, तो आप इसे src/test/resources में क्यों नहीं डालते? अगर आप कुछ संसाधन फाइलों को फ़िल्टर करना चाहते हैं, तो आप इसे क्यों नहीं करते और फ़िल्टर किए गए संसाधनों का उपयोग क्यों नहीं करते? मुझे कुछ ऐसा देखने की उम्मीद है:

<build> 
    <!-- Filter resources --> 
    <filters> 
    <filter>src/main/filters/my-filter.properties</filter> 
    </filters> 
    <!-- Resources for src/main --> 
    <resources> 
    <resource> 
     <directory>src/main/resources</directory> 
     <filtering>true</filtering> 
    </resource> 
    </resources> 
    <!-- Resources for src/test --> 
    <testResources> 
    <testResource> 
     <directory>src/test/resources</directory> 
     <filtering>true</filtering> 
    </testResource> 
    </testResources> 
</build>

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

स्रोत

2009-09-29 10:38:45

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

मुझे समझ में नहीं आ रहा है कि "दो संसाधन स्थान होने" से आपका क्या मतलब है और यह वैसे भी एक आवश्यकता नहीं है। लेकिन, यदि आपके पास अलग-अलग उत्पादन वातावरण हैं, तो क्या आपको प्रत्येक वातावरण के लिए अलग-अलग प्रबंधन नहीं करना है? लिंक इस बारे में हैं (एक मेवेन तरीके में)। –

@ पास्कल यह एक अच्छा बिंदु (+1) है, लेकिन सवाल के अन्य हिस्सों से मुझे लगता है कि ओपी का अर्थ मेवेन अर्थ में फ़िल्टर नहीं हो सकता है। इसलिए फ़ाइलों को शायद src/main/संसाधनों में जाना चाहिए। मौजूदा परियोजना संरचना के साथ काम करते समय यह संभव नहीं हो सकता है, इसलिए मेरा कामकाज –

गुण फ़ाइल के लिए जावा पथ निर्दिष्ट करना

उत्तर

संबंधित मुद्दे