बिल्ड में शामिल होने के लिए एक सामान्य चींटी फ़ाइल वितरित करने के कुछ अच्छे तरीके क्या हैं?

Question

मैं ऐसे समूह में काम करता हूं जहां हम कई छोटे ऐप्स उत्पन्न करते हैं, और हमारी निर्माण प्रक्रियाओं के लिए एएनटी का उपयोग करते हैं।

हम अपने सामान्य रूप से उपयोग किए जाने वाले निर्देशों में से कुछ को सामान्य तरीके से रखना चाहते हैं। वर्तमान में, हम एक आम स्थान के लिए एक मैप किए गए ड्राइव की आवश्यकता होती है, और प्रयोग

<import file="${env.MAPPED_DRIVE}/common_directive.xml"> 

एक बेहतर तरीका एक ड्राइव को मैप करने के बिना कई परियोजनाओं में शामिल करने के लिए एक आम चींटी फ़ाइल वितरित करने के लिए होनी चाहिए। आपके पास कोई और सुझाव है?

आयात एक "शीर्ष स्तर" निर्देश है, जिसका अर्थ है कि यह किसी लक्ष्य के अंदर काम नहीं करेगा। इसलिए, मैं केवल एक लक्ष्य नहीं बना सकता जो फ़ाइल डाउनलोड करता है, और फिर इसे आयात करता है।

Answer 1

यदि आप ANT 1.8+, you could specify a URL का उपयोग कर रहे हैं और वेबसाइट पर सामान्य निर्माण खंड होस्ट करते हैं।

चींटी 1.8.0 के बाद से काम भी कर सकते हैं यूआरएल या classpath संसाधनों से आयात संसाधनों (जो यूआरएल हैं, वास्तव में)। आप को पता है कि क्या वर्तमान बिल्ड फ़ाइल के स्रोत कोई फ़ाइल या यूआरएल आप से परामर्श कर सकते हैं संपत्ति ant.file.type.projectname ( ant.file.type.builddocs ऊपर के रूप में ही उदाहरण का उपयोग) कर दिया गया है की जरूरत है जो या तो मान "फ़ाइल" या "यूआरएल" है।

Answer 2

Dominic Mitchell के यूआरएल संदर्भ एक बुरा विचार किया जा रहा है आप repeatable चाहते हैं के बारे में टिप्पणी बनाता है मुझे यह सोच कर गया ...

एक अन्य समाधान पर विचार करना है, अगर आप संस्करण नियंत्रण के लिए SVN का उपयोग कर रहे हैं, करने के लिए है SVN Externals Definition बनाएं जो common_directive.xml पर इंगित करता है।

फिर, अपने एएनटी आयात फ़ाइल संदर्भ के लिए केवल एक सापेक्ष पथ का उपयोग करें।

कभी कभी यह एक काम कर प्रतिलिपि है कि विभिन्न checkouts की एक संख्या से बाहर कर दिया जाता है के निर्माण के लिए उपयोगी है। उदाहरण के लिए, आप अलग-अलग उपनिर्देशिकाएं अलग-अलग स्थानों से एक भंडार में या शायद विभिन्न रिपॉजिटरीज़ से अलग-अलग हो सकते हैं। आप इस तरह के परिदृश्य को svn checkout का उपयोग करके कार्यशील प्रतिलिपि बनाने के लिए की कोशिश कर रहे हैं। लेकिन यदि यह लेआउट है जो आपके रिपोजिटरी का उपयोग करने वाले सभी के लिए महत्वपूर्ण है, तो अन्य सभी उपयोगकर्ता को की आवश्यकता होगी ताकि आप उसी चेकआउट ऑपरेशंस को कर सकें।

सौभाग्य से, सबवर्जन बाहरी परिभाषाओं के लिए समर्थन प्रदान करता है। एक बाहरी परिभाषा यूआरएल में स्थानीय निर्देशिका का मानचित्रण है और आदर्श एक विशेष संशोधन-संस्करण निर्देशिका का एक विशेष संशोधन है। सबवर्सन में, आप svn:externals संपत्ति का उपयोग करके समूहों में बाहरी परिभाषाओं की घोषणा करते हैं। आप svn propset या svn propedit का उपयोग करके इस प्रॉपर्टी को बना या संशोधित कर सकते हैं ("नामक अनुभाग देखें)। इसे किसी भी संस्करण निर्देशिका पर सेट किया जा सकता है, और इसकी मान बाह्य भंडार स्थान और क्लाइंट-साइड निर्देशिका दोनों का वर्णन करती है, जिस स्थान पर चेक आउट होना चाहिए।

svn:externals संपत्ति की सुविधा है कि एक बार यह एक संस्करणीकृत निर्देशिका, जो कोई चेक कि निर्देशिका के साथ एक काम की नकल भी बाहरी परिभाषा के लाभ हो जाता है पर सेट है। दूसरे शब्दों में, एक बार एक व्यक्ति का प्रयास किया गया है नेस्ट काम कर प्रति संरचना को परिभाषित, कोई और है करने के लिए परेशान-सबवर्सन, बाहर मूल काम कर प्रति की जाँच के बाद, स्वचालित रूप से भी बाहर की जाँच करेगा बाहरी कामकाजी प्रतियां।

Answer 3

मैं एक समाधान है कि एक जार एक निर्देशिका में हमारे पुन: प्रयोज्य निर्माण लिपियों युक्त फ़ाइल बनाता है बाहर काम किया है, कहते हैं कि com/उदाहरण/चींटी/sharedbuild, जो चींटी 1.8 में आयात किया जा सकता:

<project> 
    <import> 
     <javaresource name="com/example/ant/sharedbuild/java.xml"> 
      <classpath location="../../../../target/ant-shared-build.jar" /> 
     </javaresource> 
    </import> 
</project> 

मेरे मामले में यह परियोजना के लिए जावा-आधारित निर्माण करने के लिए सभी "सार्वजनिक" लक्ष्यों को परिभाषित करता है।

वाक्यविन्यास एक छोटा वर्बोज़ है, विशेष रूप से जब मैं अधिक से अधिक फ़ाइलों को शामिल करता हूं (कहें, ओएसजीआई जार बनाने की क्षमता जोड़ने के लिए)। एक antlib.xml जोड़कर जिसमें एक मैक्रोडफ़ और स्क्रिप्टडेफ़ का जार फ़ाइल (साझा बिल्ड स्क्रिप्ट के समान निर्देशिका में) का संयोजन होता है, बिल्ड फ़ाइल अब इस तरह दिख सकती है (और अब ओएसजीआई जार बंडल भी बना रही है):

<project xmlns:build="antlib:com.example.ant.sharedbuild"> 
    <taskdef uri="antlib:com.example.ant.sharedbuild" 
      classpath="../../../../target/ant-shared-build.jar" /> 
    <build:build using="java, jar, bundle" /> 
</project> 

दुर्भाग्य से, मैं macrodef या scriptdef में कोड साझा कर सकते हैं नहीं है, लेकिन वास्तव में यह कठिन नहीं है: विशेषता और प्रत्येक पर पाश का उपयोग कर पार्स करने के लिए एक छोटे से जावास्क्रिप्ट, इसमें से एक फ़ाइल नाम निकाले जाते हैं, और आयात करें।

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

<project xmlns:build="antlib:com.example.ant.sharedbuild"> 
    <property name="ant.shared.build.jar.file" 
       location="${user.home}/ant/ant-shared-build-1.5.3.jar" /> 
    <get src="http://repo.example.com/.../ant-shared-build-1.5.3.jar" 
     dest="${ant.shared.build.jar.file}" 
     skipexisting="true" /> 
    <taskdef uri="antlib:com.example.ant.sharedbuild" 
      classpath="${ant.shared.build.jar.file}" /> 
    <build:build using="java, jar, bundle" /> 
</project> 

इस के साथ कुछ समस्याएं हैं:

1. इसे फिर से वर्बोज़ मिल रहा है।
2. प्रत्येक build.xml के लिए शब्दशः दोहराया जाता है।
3. बहुत बार बार-बार बॉयलरप्लेट है, खासकर संस्करण संख्या।

इन समस्याओं को कम करने के लिए, build.xml युक्त प्रत्येक निर्देशिका में मेरे पास bootstrap.xml भी है (नाम वास्तव में कोई फर्क नहीं पड़ता)। प्रत्येक निर्माण।एक्सएमएल फिर इस फ़ाइल में शामिल हैं:

<project xmlns:build="antlib:com.example.ant.sharedbuild"> 
    <include file="bootstrap.xml" /> 
    <build:build using="java, jar, bundle" /> 
</project> 

प्रत्येक bootstrap.xml, कम से कम, यह माता पिता की bootstrap.xml है शामिल हैं:

<project> 
    <include file="../bootstrap.xml" /> 
</project> 

उच्च-स्तरीय bootstrap.xml (रूट), तो करता है जार फ़ाइल हो रही है और कस्टम कार्य बनाने, जैसा कि ऊपर के काम:

<project> 
    <property name="ant.shared.build.version" 
       value="1.5.3" /> 
    <property name="ant.shared.build.jar.filename" 
       value="ant-shared-build-${ant.shared.build.version}.jar" /> 
    <property name="ant.shared.build.jar.file" 
       location="${user.home}/ant/${ant.shared.build.jar.filename}" /> 
    <get src="http://repo.example.com/.../${ant.shared.build.jar.filename}" 
     dest="${ant.shared.build.jar.file}" 
     skipexisting="true" /> 
    <taskdef uri="antlib:com.example.ant.sharedbuild" 
      classpath="${ant.shared.build.jar.file}" /> 
</project> 

सीधे प्रश्न से संबंधित नहीं हालांकि, मैं वास्तव में macrodef दोबारा काम कर रहा हूँ और एक कस्टम चींटी कार्य में scriptdef, क्योंकि मैं एक वाक्य रचना कि इस तरह दिखता है समर्थन करने के लिए सक्षम होना चाहते हैं:

<project xmlns:build="antlib:com.example.ant.sharedbuild"> 
    <include file="bootstrap.xml" /> 
    <build:build> 
     <using> 
      <java /> 
      <bundle> 
       <manifest> 
        Import-Package: *,org.joda.time;version="[1.6.0,1.6.0]" 
        Bundle-Activator: com.example.time.impl.Activator 
       </manifest> 
      </bundle> 
     </using> 
    </build:build> 
</project> 

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

निष्कर्ष में, एक संस्करण संख्या के साथ एक जार फ़ाइल बनाकर, जिसे एक विशिष्ट फ़ाइल स्थान से स्वतंत्र वितरित किया जा सकता है या एक एससीएम उपकरण हम वास्तविक साझा कर सकते हैं लेकिन पुनरुत्पादित बनाता है।