मैं वर्तमान में एक प्रोजेक्ट पर काम कर रहा हूं जिसमें एक बड़ी परियोजना बनाने के लिए एक-दूसरे के संदर्भ में कई अलग-अलग ग्रहण परियोजनाएं शामिल हैं। क्या कोई ऐसा मुद्दा है जहां डेवलपर को खुद से पूछना चाहिए कि क्या उन्हें अपनी विकास परियोजना के तरीके पर पुनर्विचार करना चाहिए?एक वास्तविक विकास परियोजना के लिए कितने "ग्रहण परियोजनाओं" को अत्यधिक माना जाता है?
नोट: मेरी परियोजना में वर्तमान में 25+ विभिन्न ग्रहण परियोजनाएं हैं।
अंगूठे का मेरा सामान्य नियम है कि मैं प्रत्येक पुन: प्रयोज्य घटक के लिए एक नई परियोजना तैयार करूंगा। तो उदाहरण के लिए यदि मेरे पास कुछ अलग कार्यक्षमता है जिसे पैक किया जा सकता है तो एक जार के रूप में कहें, मैं एक नई परियोजना तैयार करूंगा ताकि मैं स्वतंत्र रूप से घटक का निर्माण, पैकेज और वितरण कर सकूं।
इसके अलावा, यदि कुछ परियोजनाएं हैं जिन्हें आपको लगातार परिवर्तन करने की आवश्यकता नहीं है, तो आप उन्हें केवल तभी बना सकते हैं जब आवश्यक हो और उन्हें इंडेक्सिंग पर समय बचाने के लिए ग्रहण में "बंद" रखें। भले ही आपको लगता है कि एक निश्चित घटक पुन: प्रयोज्य नहीं है, जब तक कि यह तर्क/चिंताओं के संदर्भ में शेष कोड बेस से अलग हो जाता है, आपको इसे अलग करके इसे अच्छी तरह से सेवा दी जा सकती है। कभी-कभी प्रतीत होता है कि विशिष्ट कोड किसी अन्य प्रोजेक्ट में या उसी प्रोजेक्ट के भविष्य के संस्करण में पुन: प्रयोज्य हो सकता है।
एक पूर्व नौकरी में पूरा आवेदन +170 परियोजनाओं के बाद था। हालांकि, सभी परियोजनाओं को स्थानीय रूप से जांचने के लिए शायद ही कभी जरूरी था, यहां तक कि हमारे दायरे में लगातार 30-40 परियोजनाओं को पुन: निष्पादन आदि बहुत धीमा कर दिया गया था।
वाह। यह भयानक है :( –
ईमानदार होने के लिए मुझे याद नहीं आया कि यह 170 या 270 परियोजनाएं थी, इसलिए मैंने सुरक्षित पक्ष पर प्रवेश किया। लेकिन जैसे मैंने कहा, हमें स्थानीय रूप से चेक की गई सभी परियोजनाओं की आवश्यकता नहीं है। – Ruben
लॉल, यह आश्चर्यजनक है: डी इतनी सारी परियोजनाएं क्यों हैं? उनमें से किसी के पास 20 से अधिक कक्षाएं हैं? – IAdapter
येश। प्रत्येक परियोजना के लिए एक परियोजना। यदि आप पुन: प्रयोज्य परियोजनाओं का उपयोग कर रहे हैं, तो उन्हें स्वर्ग के लिए पुस्तकालय में बनाएं। पैकेज में किसी भी पुन: प्रयोज्य परियोजनाओं को तोड़ें, यही वह है जो वे वहां हैं।
उन परियोजनाओं के लिए जार बनाएं जिन्हें आप अक्सर काम नहीं करते हैं। यह अव्यवस्था को बहुत कम करना चाहिए। यदि आप अक्सर सभी परियोजनाओं पर काम करते हैं, तो आप अपने निर्माण में लक्ष्य जोड़ सकते हैं जो आपके लिए संबंधित परियोजनाओं को झुकाएगा, जो सब कुछ एक फ़ाइल में नीचे रखता है जिसे आप कक्षा पथ पर शामिल कर सकते हैं।
संकलित करते समय, एक परियोजना आमतौर पर एक जार का परिणाम होगा। इसलिए यदि आपके आवेदन में संभावित रूप से पुन: प्रयोज्य घटक शामिल हैं, तो प्रत्येक के लिए एक परियोजना का उपयोग करना ठीक है।
मैं कई परियोजनाओं का उपयोग करने का एक बड़ा प्रशंसक हूं, मुझे लगता है कि यह संकुल के साथ मैं क्या कर सकता हूं उससे परे बड़ी चीजें तोड़ता है, और मुझे उन्मुख और नेविगेट करने में मदद करता है।
बेशक, यदि आप एक्लिप्स प्लग-इन विकसित कर रहे हैं, तो सब कुछ एक परियोजना होगी।
केवल एक चीज जिसे मैं देखना चाहता हूं, आपके स्रोत-नियंत्रण और परियोजनाओं के बीच फ़ाइलों की चाल को संभालने की क्षमता है। उपclip मुझे इसके साथ परेशानी दे रहा था, या शायद यह मेरा एसवीएन सर्वर है जो किया था।
यदि आपकी परियोजना में है कई उप-परियोजनाओं, या मॉड्यूल, जो वास्तव में आपके अंतिम आर्टिफैक्ट को लिखने के लिए आवश्यक हैं, तो यह समय है कि मैवेन जैसे कुछ और मॉड्यूल मॉड्यूल स्थापित करना है। यह ए) आपको विचारधारा के बिना स्वतंत्र रूप से प्रत्येक मॉड्यूल पर काम करने की अनुमति देगा और mvn eclipse:eclipse लक्ष्य के माध्यम से अपने विचार (और अन्य 'आईडीई) में आसान सेटअप की अनुमति देगा। इसके अतिरिक्त, जब आप अपनी पूरी शीर्ष स्तरीय परियोजना का निर्माण करते हैं, तो मैवेन निर्भरताओं की सूची से प्राप्त करने में सक्षम होंगे, जो आपने वर्णन किया है कि किस क्रम में मॉड्यूल बनाने की आवश्यकता है।
Here's a quick link via google और एक एल ink to the book Maven: The Definitive Guide, जो अध्याय 6 में एक बेहतर विवरण में समझाएगा (एक बार जब आप मूल बातें हैं)।
यह आपके प्रोजेक्ट को स्पष्ट रूप से ग्रहण से बंधे नहीं होने के लिए मजबूर करेगा। किसी विचार से स्वतंत्र बनाने में सक्षम होने का मतलब है कि जो भी श्मो आपके साथ आने वाले टूल के साथ आ सकता है और आसानी से आपके कोड बेस के साथ काम कर सकता है।
+1 बस मेवेन और बाइनरी निर्भरताओं का उपयोग करें –
नरक, हमारे पास 100 से अधिक हैं। परियोजनाओं के लिए कुछ भी लागत नहीं है।
कई अलग-अलग कार्यस्थान बनाने के लिए एक अतिरिक्त विधि है। अलग-अलग कार्यक्षेत्रों का लाभ यह है कि आप कई परियोजनाओं के कुछ दृश्य अव्यवस्था/प्रदर्शन ओवरहेड को हटा सकते हैं। आप सभी परियोजनाओं को जार करने के लिए लक्ष्य का उपयोग कर सकते हैं और उन्हें एक भंडार में डाल सकते हैं ताकि आप उन्हें प्रत्येक कार्यक्षेत्र में संदर्भित कर सकें।
यह एक कठिन सवाल है और प्रत्येक ग्रह के लिए एक ग्रहण परियोजना होने के लिए एक ग्रहण परियोजना होने से उत्तर देने का उत्तर है।
मेरे मुनाफे:
Btw, परियोजना मैं पर काम 24 ग्रहण परियोजनाओं में बांटा गया है।
उनमें से कुछ हैं, लेकिन मैं उनमें से शायद के बारे में 75% अपने दम पर पुन: प्रयोज्य नहीं हैं कहूँगा। –
रयान- दूसरे अनुच्छेद में मेरी प्रतिक्रिया देखें। – neesh
@neesh - मुझे लगता है।मुझे कहना चाहिए था कि वे तर्क के संदर्भ में अलग नहीं हैं। –