2009-11-24 14 views
15

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

+0

क्या आप हमें अपने उपयोग के मामले के बारे में कुछ और बता सकते हैं? यदि आपके मॉड्यूल पर निर्भरता है, तो आपको उन्हें बाहर करने की आवश्यकता क्यों है? –

+0

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

उत्तर

11
मेरी जानकारी के लिए

, कोई, आप निर्भरता निष्क्रिय नहीं कर सकते हैं (आप सकर्मक निर्भरता बाहर कर सकते हैं, लेकिन यह नहीं है कि आप क्या कह रहे हैं) और हाँ, क्या आप वर्तमान में पोम के साथ कर रहे हैं (मैन्युअल रूप से संपादित यह गलत है।

तो, बजाय निर्भरता को दूर करने के लिए, आप उन्हें एक प्रोफाइल में डाल दिया और चाहिए या तो:

  • विकल्प # 1: प्रोफ़ाइल का उपयोग जरूरत पड़ने पर या
  • विकल्प # 2: प्रोफाइल के रूप में चिह्नित से सक्रिय डिफ़ॉल्ट या सक्रिय प्रोफाइल की सूची में डाल दें और आवश्यक होने पर इसे निष्क्रिय करें।

एक तीसरा विकल्प (आधारित प्रोफ़ाइल नहीं) किया जाएगा:

  • विकल्प # 3: दो अलग मॉड्यूल में अलग बातें (जैसा कि आप चिंताओं अलग किया है) और उपयोग विरासत।
+0

उस दृष्टिकोण के साथ समस्या यह है कि मुझे निर्भरता की ज़रूरत है कि हर समय वहां काफी कुछ हो। मुझे हर 3 महीने में एक बार लक्ष्य मंच बनाना होगा। इसलिए प्रत्येक बिल्ड पर एक प्रोफाइल निर्दिष्ट करना हाथ से पीओएम संपादित करने की तुलना में परेशानी का अधिक है। डिफ़ॉल्ट रूप से सक्रिय प्रोफाइल प्रोफाइल दुर्भाग्यवश निष्क्रिय हो जाते हैं जब कोई अन्य प्रोफ़ाइल सक्रिय होती है, जिससे यह मेरी सहायता नहीं करेगा क्योंकि अक्सर एक और प्रोफ़ाइल सक्रिय होती है। –

+0

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

+0

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

3

मुझे नहीं लगता कि यह प्रत्यक्ष निर्भरता या तो (कम से कम कुछ भी नहीं here उल्लेख किया गया है) हटाना संभव है।

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

<profiles> 
    <profile> 
    <id>default-profile</id> 
    <activation> 
     <property><name>!exclude</name></property> 
    </activation> 
    <dependencies> 
     dependency-A 
     dependency-B 
     ... 
    </dependencies> 
    </profile> 

    <profile> 
    <id>exclude-profile</id> 
    <activation> 
     <property><name>exclude</name></property> 
    </activation> 
    <!-- exclude/replace dependencies here --> 
    </profile> 
</profiles> 

तब का उपयोग कर "mvn [लक्ष्य]" प्रोफाइल "डिफ़ॉल्ट प्रोफ़ाइल" का प्रयोग करेंगे, लेकिन "mvn [लक्ष्य] -Dexclude" प्रोफ़ाइल का उपयोग करेगा "को बाहर-प्रोफाइल"।

ध्यान दें कि आपकी "डिफ़ॉल्ट" प्रोफ़ाइल के पैरामीटर के बजाय 'activeByDefault' का उपयोग कुछ मामलों में काम कर सकता है लेकिन इससे अप्रत्याशित व्यवहार भी हो सकता है। समस्या यह है कि 'activeByDefault' एक प्रोफ़ाइल सक्रिय करता है जब तक कि बहु-मॉड्यूल निर्माण के किसी अन्य मॉड्यूल में कोई अन्य सक्रिय प्रोफ़ाइल न हो।

5

एक तरीका जो मेरे साथ होता है वह निर्भरता को एक अलग पोम में रखना है। फिर आप प्रोफाइल के माध्यम से <exclusions> अनुभाग जोड़ सकते हैं।

<dependencies> 
    <dependency> 
     <groupId>my.company.dependencies</groupId> 
     <artifactId>my-dependencies</artifactId> 
     <version>1.0.0-SNAPSHOT</version> 
     <type>pom</type> 
    </dependency> 
</dependencies> 

<profile> 
    <activation> 
     <activeByDefault>false</activeByDefault> 
     <property> 
      <name>exclude-deps</name> 
     </property> 
    </activation> 

    <dependencies> 
     <dependency> 
      <groupId>my.company.dependencies</groupId> 
      <artifactId>my-dependencies</artifactId> 
      <version>1.0.0-SNAPSHOT</version> 
      <type>pom</type> 
      <exclusions> 
       <exclusion> 
        <groupId>my.company</groupId> 
        <artifactId>bad-dep-1</artifactId> 
       </exclusion> 
       <exclusion> 
        <groupId>my.company</groupId> 
        <artifactId>bad-dep-2</artifactId> 
       </exclusion> 
      </exclusions> 
     </dependency> 
</dependencies> 
</profile> 
4

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

वांछित प्रोफाइल में, dependencies अनुभाग जोड़ें, उन लोगों की घोषणा की प्रतिलिपि बनाएँ जिन्हें आप बाहर करना चाहते हैं और उन्हें provided के रूप में दायरा दें।

उदाहरण के लिए, मान लीजिए कि आप slf4j-log4j12 बाहर करना चाहते हैं:

<profiles> 

    <!-- Other profiles --> 

    <profile> 
     <id>no-slf4j-log4j12</id> 
     <dependencies> 
      <dependency> 
       <groupId>org.slf4j</groupId> 
       <artifactId>slf4j-log4j12</artifactId> 
       <version>1.7.2</version> 
       <scope>provided</scope> 
      </dependency> 
     </dependencies> 
    </profile> 

    <!-- Other profiles --> 

</profiles> 
0

बिट गंदा लेकिन हल्के समाधान <scope>import</scope> उपयोग करने के लिए है।

अन्य कार्यक्षेत्रों के विपरीत आप इस इस्तेमाल कर सकते हैं:

  • संकलन समय और क्रम dependecies को निष्क्रिय कर देगा; provided या runtime जो एक समय में केवल एक को निष्क्रिय विपरीत
  • होगा गंदगी नहीं अपने test गुंजाइश
  • आप के रूप में system गुंजाइश की आवश्यकता होगी

कुछ भी नहीं हो जाता है कुछ डमी जार करने के लिए पथ निर्दिष्ट करने के लिए की जरूरत नहीं है जब तक आप इस हैक का उपयोग dependencyManagement के बाहर करते हैं तब तक आयात किया जाता है।

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