के साथ अच्छी तरह से एकीकृत है मैं कई मॉड्यूल (लगभग 10 वर्तमान में) पर एक छोटी टीम (3 व्यक्तियों) में काम कर रहा हूं। निर्माण संस्करणों का संकलन, एकीकरण और प्रबंधन अधिक से अधिक कठिन हो रहा है। मैं चींटी को प्रतिस्थापित/पूर्ण करने के लिए एक अच्छा निर्माण/एकीकरण उपकरण ढूंढ रहा हूं।एक अच्छा जावा निर्माण उपकरण पर सलाह, ग्रहण
यहाँ हमारे वर्तमान विकास के वातावरण का वर्णन है: - प्रत्येक पर पर और तीसरे पक्ष के जार के आधार पर कई मॉड्यूल - कुछ (फैट-जार) के साथ जार, कुछ निर्यात युद्ध, कुछ निर्यात स्टैंडअलोन, runnable जार निर्यात कर सकते हैं - उन सभी के लिए जावाडोक - हम ग्रहण - प्रत्येक मॉड्यूल के लिए कस्टम एंट स्क्रिप्ट के साथ काम करते हैं। ग्रहण विन्यास और चींटी स्क्रिप्ट के बीच कई अनावश्यक जानकारी। उदाहरण के लिए, स्टैंडअलोन फैट-जेएआर के लिए, हमने सभी रिकर्सिव निर्भरताओं को सूचीबद्ध किया है, जबकि आदर्श रूप से, यह स्पष्ट रूप से ग्रहण विन्यास से आयात किया जा सकता है। - स्रोत कोड SVN
यहाँ है का उपयोग कर रहा मेरे लिए क्या करने के लिए एक आदर्श एकीकरण उपकरण चाहते हैं क्या संस्करणीकृत है:
automatize विज्ञप्ति और मॉड्यूल के संस्करण। आदर्श रूप से, एकीकरण उपकरण को पता होना चाहिए कि क्या एक नया संस्करण आवश्यक है। उदाहरण के लिए, यदि मैं प्रोजेक्ट ए को रिलीज़ करना चाहता हूं जो कि प्रोजेक्ट बी पर निर्भर करता है, और यदि मैंने स्थानीय रूप से प्रोजेक्ट बी पर छोटे बदलाव किए हैं, तो एकीकरण टूल को पहले बी के नए संस्करण को भी रिलीज़ करना चाहिए और ए पर आधारित होना चाहिए यह।
ग्रहण के साथ दृढ़ता से एकीकृत करें, ताकि यह मॉड्यूल और तृतीय पक्ष libs के बीच इसकी कॉन्फ़िगरेशन के बीच निर्भरता प्राप्त कर सके। बीटीडब्लू, मैं कुछ अन्य ".xml" सामग्री को अपडेट किए बिना ग्रहण के साथ बिल्ड पथ को कॉन्फ़िगर करना जारी रखना चाहता हूं। मैंने देखा कि ग्रैडल ग्रहण परियोजना फ़ाइलों को इसकी कॉन्फ़िगरेशन से उत्पन्न कर सकता है, लेकिन समकक्ष बहुत अच्छा होगा।
स्थानीय परियोजनाओं पर "लाइव" और पारदर्शी विकास सक्षम करें। मेरा मतलब है कि मुख्य/"पत्ती" परियोजनाओं के विकास के दौरान मैं अक्सर कोर/आम परियोजनाओं पर छोटे बदलाव करता हूं। मैं अपनी मूल परियोजनाओं के जेएआर को प्रकाशन (यहां तक कि स्थानीय रूप से) की आवश्यकता के बिना तत्काल लीफ परियोजनाओं के लिए उपलब्ध मूल परियोजनाओं पर अपने परिवर्तन करना चाहता हूं।
बाहरी मॉड्यूल पर मेरे मॉड्यूल के रिलीज़ के सभी संस्करणों को स्टोर करें। सबसे सरल (शेयर फ़ोल्डर/वेबडाव) सबसे अच्छा होगा। मॉड्यूल की सूची और वितरित कलाकृतियों के साथ एक अच्छा वेब पेज भी बहुत अच्छा होगा।
मैंने कई चीजों के लिए चारों ओर देखा है। Ant4eclipse से (ग्रहण विन्यास को मेरी चींटी लिपि में एकीकृत करने के लिए), मेवेन/आइवी/ग्रैडल टूल्स तक।
मैं थोड़ा उलझन में हूं। यहां तक कि मैंने जो कुछ भी समझा है, वह है: - मेवेन एक महान/बड़ा उपकरण है, लेकिन कुछ हद तक कठोर है और आप इसकी संरचना और अवधारणाओं को झुकाव के लिए बाध्य करते हैं। यह स्क्रिप्टिंग के बजाय विवरण पर आधारित है। यदि आप पथ से बाहर जाते हैं, तो आपको अपने प्लगइन विकसित करना होगा। - आइवी मेवेन से कम शक्तिशाली है, यह कम सामान को संभालता है लेकिन अधिक लचीला है। - ग्रैडल बीच में है। यह सामान्य उद्देश्य है। यह स्क्रिप्टिंग के साथ-साथ "सम्मेलन आधारित" कॉन्फ़िगरेशन को सक्षम बनाता है। यह चींटी को एकीकृत करता है और इसे बढ़ाता है।
तो इस बिंदु पर मैं वास्तविक उपयोगकर्ताओं से वास्तविक प्रशंसापत्र ढूंढ रहा हूं। आप किस उपकरण का उपयोग करते हैं? कैसे ? क्या आपके पास वही ज़रूरत है? क्या यह आपके जीवन को कम करता है या रास्ते में आता है?
क्या वहां कुछ उपयोग मामलों या वर्कस्पेस कंकाल का नमूना है, जहां मैं यह देखने के लिए शुरुआती बिंदु के रूप में उपयोग कर सकता हूं कि ये उपकरण क्या सक्षम हैं?
इस संदेश की लंबाई के लिए खेद है। और सलाह के लिए अग्रिम धन्यवाद।
सधन्यवाद,
राफेल
एक निर्माण उपकरण (जैसे चींटी, चींटी + आइवी, ग्रैडल, मेवेन 2, आदि) या एक निरंतर एकीकरण इंजन (जैसे हडसन, क्रूज़ कंट्रोल, बांस, टीमसिटी, आदि)? बिल्ड टूल्स वास्तव में सीआई टूल्स नहीं हैं (इन्हें प्राथमिक सीआई प्रक्रिया को लागू करने के लिए इस्तेमाल किया जा सकता है लेकिन मैं उन्हें सीआई टूल्स के रूप में नहीं मानता)। आपको शायद स्पष्टीकरण देना चाहिए। –
हाँ आप सही हैं, यह निरंतर एकीकरण नहीं है जिसे मुझे चाहिए, बल्कि उपकरण बनाएं। मैं इसे शीर्षक में बदलता हूं। –