2010-11-16 3 views
6

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

मैं ऐसे समाधान की तलाश में हूं जो इसे बनाए रखना आसान होगा, इसका मतलब है कि विभिन्न स्थानों पर मौजूद कई फाइलें नहीं हैं।

उत्तर

6

वरीयताओं के लिए एक सरल दृष्टिकोण File>Import और File>Export, चुनने General>Preferences, तो वरीयताओं आप साझा करना चाहते का प्रयोग है। मेरी कुछ पिछली टीमों के लिए, हमने बेसलाइन प्राथमिकताओं को संस्करण नियंत्रण में संग्रहीत किया।

+0

धन्यवाद, बस इस पर ठोकर खाई - यह वही था जो मैं खोज रहा था। मुझे आज एक नया देव बॉक्स मिला और मुझे अपनी कुंजी बाइंडिंग/प्रीफ़्स को एक प्राचीन ग्रहण स्थापित करने की प्रतिलिपि बनाने की आवश्यकता थी। एक जादू की तरह काम किया... – evadeflow

2

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

वाणिज्यिक सॉफ्टवेयर भी है जो यह सब आपके लिए करेगा, अगर मैं इसे पा सकूं तो मैं लिंक पोस्ट करूंगा।

उम्मीद है कि इससे मदद मिलती है।

3

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

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

-1

आपको यह article from DeveloperWorks उपयोगी मिल सकता है। यह दिखाता है कि आसान तरीके से प्लगइन का प्रबंधन कैसे करें

+0

-1, लिंक फ़ोल्डर अद्यतन प्रबंधक की अवधि में प्लग-इन प्रबंधित करने का एक विरासत तरीका है। पी 2 प्रावधान प्रबंधक होने के बाद इसकी अनुशंसा नहीं की जाती है, और यह भविष्य में बहिष्कृत हो सकती है। – Kane

1

मुझे साइट पर question में एक समाधान मिला।
यह workspace mechanic नामक एक प्लगइन की सिफारिश करता है। ऐसा लगता है कि यह वरीयताओं और विन्यास मुद्दों को हल करता है।
मैं इसका उपयोग कर रहा हूं और यह कॉन्फ़िगरेशन के लिए अच्छा दिखता है। हालांकि प्लगइन के लिए यह समाधान नहीं देता है।

1

मैंने similar question से पूछा और Yoxos की सिफारिश की गई थी। हैवेन्ट के पास अभी तक कोशिश करने का समय था, लेकिन यह आशाजनक लग रहा है।

0

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

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

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

पीडीई/दुर्भाग्य से बिल्ड परिभाषाओं के बारे में नहीं पता है, लेकिन फ़ाइल प्रारूप को समझने में काफी आसान है।

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

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