2011-03-14 18 views
12

में निर्भर जार रखते हुए, तो मेरे पास कई निर्भर जारों के साथ एक युद्ध परियोजना है जो किसी भी भंडार में उपलब्ध नहीं है। हाल ही में, मैं उन्हें src/main/webapp/WEB-INF/lib में रख रहा था, और उन्हें system scope के साथ पोम में जोड़ रहा था।मेवेन: प्रोजेक्ट वर्जन कंट्रोल

मुझे लगता है कि यह समस्याग्रस्त है, इसलिए मैं अपना निर्माण साफ़ करना चाहता हूं। मैंने प्लगइन के माध्यम से अपने .m2/repository में अर्द्ध मैन्युअल रूप से जार स्थापित किए हैं। यह मेरे लिए बहुत अच्छा है, लेकिन मेरी टीम के अन्य लोगों के बारे में क्या? हम छोटे हैं, और नेक्सस स्थापित करना वास्तव में हमारे लिए एक विकल्प नहीं है। मैंने प्रत्येक जार के लिए install:install-file को चलाने के तरीके को समझाते हुए pom.xml पर टिप्पणी जोड़ने का सहारा लिया है।

मैं install:install-file समाधान के साथ ठीक हूँ, लेकिन मैं अभी भी था की तरह अपने प्रोजेक्ट के संस्करण नियंत्रण में इन कलाकृतियों में शामिल हैं, न कि केवल उन्हें अपने फाइल सिस्टम के बारे में छिड़का की है।

उन्हें src/main/webapp/WEB-INF/lib में रखते हुए काम नहीं करता है, क्योंकि यह स्वचालित रूप से उन्हें परिणामस्वरूप युद्ध आर्टिफैक्ट में जोड़ता है (digression: अगर मैवेन बस आगे बढ़ेगा और उन्हें क्लासपाथ में जोड़ देगा तो मैं करूँगा, इंस्टॉल करने की कोई आवश्यकता नहीं है: स्थापित-फाइल)

प्रश्न:! वहाँ Maven निर्देशिका लेआउट में एक स्वीकृत की जगह है जहाँ मैं इन .jar फ़ाइलों टक सकते हैं, बस इतना है कि मैं उन्हें अपने परियोजना के हिस्से के रूप में रख सकते है?

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

+3

नेक्सस सेट करना बहुत आसान है। मेरे पास सिर्फ घर पर ही एक उदाहरण चल रहा है। – ColinD

+0

क्या यह नेक्सस के साथ स्थानीय भंडार बनाने के लिए बहुत अधिक होगा? आप इसे सभी मैवेन रिपो के लिए प्रॉक्सी और उन तृतीय पक्ष जार रखने के लिए उपयोग कर सकते हैं। – Augusto

+3

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

उत्तर

5

हैं के रूप में जन ने सुझाव दिया नेक्सस या सिर्फ एक सरल fileserver रेपो की स्थापना वास्तव में बहुत ज्यादा मुसीबत है, यहाँ कुछ अन्य विकल्प हैं:

  • सीधे शब्दों में जार और एक स्क्रिप्ट है कि उन्हें स्थापित करेंगे शामिल सभी संस्करण नियंत्रण में अपनी पसंद की निर्देशिका में। इसे मंजूरी देने के लिए मेवेन संरचना की कोई ज़रूरत नहीं है।
  • भंडार के लिए मेजबान के रूप में अपने संस्करण नियंत्रण प्रणाली का उपयोग करें, या तो अपनी मुख्य परियोजना में या एक अलग परियोजना के रूप में स्वयं शाखा में। आपके पास पहले से ही संस्करण नियंत्रण पर मौजूद किसी भी बैकअप, सुरक्षा इत्यादि को उन फ़ाइलों के सेट में जार शामिल किए बिना भंडार पर लागू होता है, जिन्हें वास्तव में चेक आउट किया गया है और प्रतिबद्ध किया गया है।
  • एक फ़ोल्डर में जार शामिल करें जो मिनी-रिपॉजिटरी के रूप में कार्य करता है जो शेष कोड के साथ चेक आउट किया जाता है। उस फ़ोल्डर में pom.xml बिंदु को एक रिपोजिटरी के रूप में उपयोग करें। मुझे 100% यकीन नहीं है कि यह संभव है, लेकिन ऐसा लगता है कि यह है।
+0

हम आपके पहले सुझाव का पालन करते हैं। मेवेन आपके अंतिम सुझाव का समर्थन नहीं करता है। –

+0

+1: अंतिम सुझाव भी काम करता प्रतीत होता है (मेवेन 2.2.1 का उपयोग करके)। – Lars

+2

मैं लगभग आपको जवाब देने के लिए बस एक +1 देना चाहता हूं "लेकिन वास्तव में, नेक्सस स्थापित करना मुश्किल नहीं है।" :-) नेक्सस जैसे टूल को स्थापित करने वाली कुछ (कई?) परियोजनाओं पर बस एक विकल्प नहीं है। और मुख्य स्रोत रेपो के बाहर कलाकृतियों को रखना सिर्फ एक अच्छा विचार नहीं है यदि आपके पास उस बाहरी भंडार को सावधानीपूर्वक बनाए रखने के लिए टीम/संसाधन नहीं हैं, जैसा कि आप अपना स्रोत रेपो करेंगे। चींटी का उपयोग करने वाले लोग सिर्फ एक lib निर्देशिका में जार सामान और वे कर रहे हैं। मैं अक्सर चाहता हूं कि मैवेन "सरल चीजें सरल होनी चाहिए" मंत्र अपनाएंगे। आपके प्रतिक्रिया के लिए धन्येवाद। –

2

मुझे लगता है कि आपके मामले में सबसे अच्छा समाधान आंतरिक भंडार स्थापित करना होगा। पहले पूरे नेक्सस को सेट करने की आवश्यकता नहीं है। कोई भी सरल वेबसर्वर कहीं भी पर्याप्त या साझा फ़ोल्डर होगा।

एक आंतरिक भंडार स्थापित करने के लिए Maven DOC देखें।

+0

लेकिन क्या होगा अगर एक आंतरिक भंडार एक विकल्प नहीं है? – Lars

+2

मेवेन में इंस्टॉल शामिल है: इस उद्देश्य के लिए बस इंस्टॉल करें। ~/.m2/भंडार/नेटवर्क/मेवेन/भंडार में रखना कितना मुश्किल है? हो सकता है कि नेक्सस ओवरकिल हो, हो सकता है कि HTTP ओवरकिल हो, लेकिन फाइल सर्वर? वे कभी भी विकल्प क्यों नहीं हैं? –

+1

@Chris पर्याप्त जटिल कंपनी में स्रोत नियंत्रण सर्वर सभी इच्छुक पार्टियों के लिए एकमात्र सर्वर पहुंच योग्य हो सकता है; और लंबी अवधि के दौरान एक आंतरिक मैवेन भंडार सबसे अच्छा विकल्प हो सकता है, अंतरिम को पुल करने के लिए कुछ आवश्यक है। – Lars

2

मेरी कंपनी में हम Archiva का उपयोग कर रहे हैं, यह अब तक का सबसे आसान रिपोजिटरी प्रबंधक स्थापित करने और बनाए रखने के लिए है।विशेष रूप से यदि आप स्टैंड-अलोन आधारित संस्करण के साथ जाते हैं। आंतरिक डेवलपर को इंगित करने के लिए प्रत्येक डेवलपर बस profile को ~/.m2/settings.xml फ़ाइल में सेट करता है। यदि यह बहुत अधिक परेशानी है, तो में सीधे <repositories/> में आंतरिक भंडार डालें, लेकिन यह वास्तव में खराब अभ्यास है। यदि रिपोजिटरी यूआरएल कभी भी चलता है, तो आपको अपनी सभी परियोजनाओं को pom.xml फ़ाइलों को अपडेट करना होगा। जहां settings.xml का उपयोग करने के रूप में डेवलपर पर उस बोझ को स्थानीय कॉन्फ़िगरेशन अपडेट करने के लिए कहते हैं।

<?xml version="1.0" encoding="UTF-8"?> 
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> 
    <profiles> 
     <profile> 
      <id>internal</id> 
      <activation> 
       <activeByDefault>true</activeByDefault> 
      </activation> 
      <repositories> 
       <repository> 
        <id>mycompany.internal</id> 
        <name>Internal Release Repository</name> 
        <url>http://maven.mycompany.com/repository/internal/</url> 
        <releases> 
         <enabled>true</enabled> 
        </releases> 
        <snapshots> 
         <enabled>false</enabled> 
        </snapshots> 
       </repository> 
       <repository> 
        <id>mycompany.snapshots</id> 
        <name>Internal Snapshot Repository</name> 
        <url>http://maven.mycompany.com/repository/snapshots/</url> 
        <releases> 
         <enabled>false</enabled> 
        </releases> 
        <snapshots> 
         <enabled>true</enabled> 
        </snapshots> 
       </repository> 
      </repositories> 
     </profile> 
    </profiles> 


    <servers> 
     <server> 
      <id>internal</id> 
      <username>guest</username> 
     </server> 
     <server> 
      <id>snapshots</id> 
      <username>guest</username> 
     </server> 
    </servers> 

</settings> 

तो एक भंडार प्रबंधक की स्थापना बहुत ज्यादा मुसीबत है, मैं तुम्हें हाथ से अपने स्थानीय भंडार है, जो बहुत त्रुटि प्रवण और समय लगता है के लिए सामान मैन्युअल रूप से जोड़ना के वैकल्पिक पर पुनर्विचार करने की जरूरत है। मैं अपने व्यक्तिगत विकास के लिए एक आर्किवा इंस्टेंस चलाता हूं क्योंकि release प्रत्येक मशीन पर अपने स्थानीय भंडार में सामान जोड़ने के लिए आवश्यक सभी आर्केन -D विकल्पों को याद किए बिना संस्करणों को प्लग और प्रबंधित करना इतना आसान है। ~/.m2/settings.xml फ़ाइल की प्रतिलिपि बनाना बहुत आसान है और यदि यह एक मशीन पर काम करता है तो यह उन सभी पर काम करता है।

यह है कि आप अपने pom.xml में जो कुछ भी जोड़ते हैं, वह स्वचालित रूप से रिलीज करने और कलाकृतियों को एक भंडार में धक्का देने में सक्षम बनाता है, मेरे मामले में यह आर्किवा है।

<distributionManagement> 
    <repository> 
     <id>internal</id> 
     <name>Internal Archiva Repository</name> 
     <url>http://maven.mycompany.com/repository/internal/</url> 
     <layout>default</layout> 
     <uniqueVersion>false</uniqueVersion> 
    </repository> 
    <snapshotRepository> 
     <id>snapshots</id> 
     <name>Internal Archiva Repository</name> 
     <url>http://maven.mycompany.com/repository/snapshots/</url> 
     <layout>default</layout> 
     <uniqueVersion>false</uniqueVersion> 
    </snapshotRepository> 
</distributionManagement> 

फिर तुम सब mvn clean release:prepare है स्वचालित रूप से आपके pom.xml संस्करण में जांच, टैग और वैकल्पिक रूप से शाखा रिहाई को अद्यतन करने और सभी कलाकृतियों पैकेज, और फिर mvn release:perform दूरदराज के कलाकृतियों को पुश करने के लिए भंडार और नए संस्करण pom.xml में जांचें और आप विकास शुरू करने के लिए अगले संस्करण के लिए तैयार हैं।

स्नैपशॉट्स snaphots गया और विज्ञप्ति में रिलीज प्लग के साथ स्वचालित रूप से internal में जाते हैं। साथ ही आप में एससीएम प्लग को कॉन्फिगर करना है, लेकिन है कि बस विन्यास की कुछ लाइनें है कि आप केवल एक बार के साथ-साथ स्पर्श करने की आवश्यकता है ।

यह यह कैसा Git के लिए, हम अपने Git भंडार प्रबंधक के रूप में Gitorious उपयोग कर रहे हैं लगता है

<scm> 
    <connection>scm:git:git://gitorious.mycompany.com:myproject/myproject.git</connection> 
    <developerConnection>scm:git:ssh://[email protected]/myproject/myproject.git</developerConnection> 
    <url>http://gitorious.mycompany.com/myproject/myproject</url> 
</scm> 

एक पुरानी डेस्कटॉप कंप्यूटर खरीद शामिल किए बिना चल लिनक्स एक विकास दल के लिए इस तरह भंडार कर्तव्यों संभाल कर सकते हैं और यह।

2

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

<?xml version="1.0" encoding="utf-8"?> 
<project> 
    <modelVersion>4.0.0</modelVersion> 
    <name>Depending project</name> 

    <groupId>com.example</groupId> 
    <artifactId>dependent</artifactId> 
    <version>0.9</version> 
    <packaging>jar</packaging> 

    <dependencies> 
    <dependency> 
     <groupId>com.example</groupId> 
     <artifactId>dependency</artifactId> 
     <version>0.9.3</version> 
     <type>jar</type> 
    </dependency> 
    </dependencies> 

    <repositories> 

    <repository> 
     <id>project-specific-deps</id> 
     <name>project-specific-deps</name> 
     <url>file:///${basedir}/repo</url> 
    </repository> 

    </repositories> 

</project> 

उदाहरण पेड़ तो जैसे:

. 
|-- pom.xml 
|-- repo 
| `-- com 
|  `-- example 
|   `--dependency 
|    |-- 0.9.3 
|    | |-- dependency-0.9.3.jar 
|    | |-- dependency-0.9.3.jar.md5 
|    | |-- dependency-0.9.3.jar.sha1 
|    | |-- dependency-0.9.3.pom 
|    | |-- dependency-0.9.3.pom.md5 
|    | `-- dependency-0.9.3.pom.sha1 
|    |-- maven-metadata.xml 
|    |-- maven-metadata.xml.md5 
|    `-- maven-metadata.xml.sha1 
|-- src 
| `-- main 
|  `-- java 
|   `-- com 
|    `-- example 
|     `-- dependent 
|      `-- Foobar.java 

कैसे कि आवाज़ कैसी है?

पूर्णता के लिए:

$ mvn -version 
Apache Maven 2.2.1 (rdebian-4) 
Java version: 1.6.0_20 
Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre 
Default locale: sv_SE, platform encoding: ISO-8859-1 
OS name: "linux" version: "2.6.32-3-686" arch: "i386" Family: "unix" 
3

यहां पहले से ही अच्छा जवाब के बहुत सारे हैं, और आप दृढ़ता से अपने समूह के लिए इस तरह के Archiva के रूप में एक भंडार प्रबंधक की स्थापना पर विचार करना चाहिए, क्योंकि यह अन्य लाभ अब और अधिक प्रदान करेंगे पहर।खुद निहित आत्म http://brettporter.wordpress.com/2009/06/10/a-maven-friendly-pattern-for-storing-dependencies-in-version-control/

कृपया ध्यान रखें चेतावनी है कि यह प्रयोग किया जा रहा करने के लिए परियोजना को सीमित करता है - अगर:

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

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