ग्रहण कार्यक्षेत्र: क्या और क्यों?


133

मैंने कार्यक्षेत्र (प्रति परियोजना, प्रति एप्लिकेशन (बहु-परिसंपत्ति या नहीं), प्रति प्रोग्राम भाषा, प्रति लक्ष्य (वेब-डेवलपमेंट, प्लगइन्स, ..), और इसी तरह का उपयोग करने के विभिन्न तरीकों को देखा, पढ़ा और सोचा है। मुझे अभी भी संदेह है कि सबसे अच्छा तरीका क्या है।

किसी भी तरह एक विस्तृत दे सकते हैं, लेकिन इस में एक पृष्ठ लंबी अंतर्दृष्टि नहीं है?

इसमें बहुत सारे उप-प्रश्न शामिल हैं, इसलिए बोलने के लिए, और मुझे उन सभी विशिष्ट उप-प्रश्नों की जानकारी नहीं है, जिन्हें मुझे पूछना चाहिए, क्योंकि मुझे यकीन नहीं है कि मैं ग्रहण (और कार्यक्षेत्र) के सभी पहलुओं को नहीं जानता, लेकिन मैं एक उदाहरण देने की कोशिश करूँगा जो मैं देख रहा हूँ:

  • किस लिए?
    • ग्रहण के विकास का क्या मतलब था?
    • अन्य / अधिकांश लोग क्या सोचते हैं?
    • तुम क्या सोचते हो?
    • ...?
  • क्यों?
    • क्या कॉन्फ़िगरेशन विरोध बनाम साझाकरण गुण हैं?
    • किसी भी कारण से?
    • प्रदर्शन?
    • ...?

ओह, और मैं एक डेवलपर के लिए न्यूनतम उपयोग के मामले की बात कर रहा हूं जो विभिन्न भाषाओं और प्रोटोकॉल का उपयोग करता है, और जरूरी नहीं कि उन सभी को एक परियोजना में (जैसे कि कुछ परियोजनाओं के लिए एग php, जावास्क्रिप्ट और xml, दूसरों के लिए C #, java और SQL अभी भी हो। अन्य, आदि ..)

2012-11-27 को संपादित करें: मुझे गलत मत समझिए। मुझे कार्यक्षेत्रों के उपयोग पर संदेह नहीं है, मैं बस इसका उपयोग करना चाहता हूं क्योंकि यह होना चाहिए या अन्यथा अगर कोई इसे बेहतर समझेगा। तो "किस लिए?" का अर्थ है: सबसे अच्छा उपयोग क्या है? और क्यों?" वास्तव में "क्या है?" पर लक्षित, दूसरे शब्दों में: मुझे अपने उत्तर के कारण बताएं।


14
मैं अभी भी नहीं मिला। यह स्पष्ट रूप से केवल उन लोगों के लिए समझ में आता है जो पहले से ही जानते हैं कि उनके लिए क्या है , और उनके लिए यह समझना मुश्किल है कि यह बाकी सभी लोगों के लिए स्पष्ट नहीं है।
राफेल Eyng

मुझे यह नहीं मिलता है और मैं नीचे दी गई हर चीज से सहमत नहीं हूं, और न ही यह पूरा है (कोई संदर्भ नहीं)। मैंने अभी तक उत्तर क्यों स्वीकार नहीं किया। * बेशक वहाँ जहाँ यह एक राय या व्यक्तिगत अभ्यास नहीं है। मुझे लगता है कि
ई-प्रेरक

मैंने इसका उत्तर देने की कोशिश की है, यह बहुत अच्छा उत्तर नहीं है, लेकिन मुझे लगता है कि मैं इसके शीर्ष पर निर्माण कर सकता हूं
राफेल इयंग

जवाबों:


43

मैं आपको किसी ऐसे व्यक्ति के बारे में अपनी दृष्टि प्रदान करूँगा, जो जावा दुनिया में बहुत असहज महसूस करता है, जो मुझे लगता है कि आपका मामला भी है।

यह क्या है

एक कार्यक्षेत्र एक साथ समूहीकरण की एक अवधारणा है:

  1. (किसी तरह) संबंधित परियोजनाओं का एक सेट
  2. इन सभी परियोजनाओं से संबंधित कुछ विन्यास
  3. खुद ग्रहण के लिए कुछ सेटिंग्स

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

ऊपर प्रत्येक आइटम की खोज:

  1. (किसी तरह) संबंधित परियोजनाओं का एक सेट

ग्रहण हमेशा एक विशेष कार्यक्षेत्र के साथ मिलकर खोला जाता है, अर्थात, यदि आप कार्यक्षेत्र A में हैं और कार्यक्षेत्र B पर स्विच करने का निर्णय लेते हैं (फ़ाइल> स्विच कार्यस्थान), तो ग्रहण स्वयं बंद हो जाएगा और फिर से खुल जाएगा। वे सभी प्रोजेक्ट जो कार्यक्षेत्र A से संबद्ध थे (और प्रोजेक्ट एक्सप्लोरर में दिखाई दे रहे थे) अब दिखाई नहीं देंगे और कार्यक्षेत्र B से जुड़े प्रोजेक्ट अब दिखाई देंगे। तो ऐसा लगता है कि एक्लिप्स में खुला रहने के लिए एक परियोजना, एक कार्यक्षेत्र से जुड़ी होनी चाहिए

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

इस तरह, एक परियोजना एक बार में 1 से अधिक कार्यक्षेत्र के अंदर हो सकती है। इसलिए अपने कार्यक्षेत्र और अपने स्रोत कोड को अलग रखना अच्छा लगता है।

  1. इन सभी परियोजनाओं से संबंधित कुछ विन्यास

मैंने सुना है कि जावा कंपाइलर संस्करण की तरह कुछ (जैसे 1.7, जैसे - मुझे नहीं पता कि 'संस्करण' यहां शब्द है), एक कार्यक्षेत्र-स्तरीय कॉन्फ़िगरेशन है। यदि आपके पास अपने कार्यक्षेत्र के अंदर कई परियोजनाएं हैं, और उन्हें ग्रहण के अंदर संकलित करते हैं, तो उन सभी को एक ही जावा बॉयलर के साथ संकलित किया जाएगा।

  1. खुद ग्रहण के लिए कुछ सेटिंग्स

आपकी कुंजी बाइंडिंग जैसी कुछ चीजें कार्यक्षेत्र-स्तर पर भी संग्रहीत की जाती हैं। इसलिए, यदि आप परिभाषित करते हैं कि ctrl + टैब स्मार्ट तरीके से टैब स्विच करेगा (उन्हें स्टैकिंग नहीं), तो यह केवल आपके वर्तमान कार्यक्षेत्र के लिए बाध्य होगा। यदि आप उसी कुंजी बाइंडिंग को किसी अन्य कार्यक्षेत्र में उपयोग करना चाहते हैं (और मुझे लगता है कि आप चाहते हैं!), तो ऐसा लगता है कि आपको उन्हें कार्यक्षेत्रों के बीच निर्यात / आयात करना होगा (यदि यह सच है, तो यह आईडीई कुछ बहुत ही अजीब परिसर में बनाया गया था)। इस पर एक लिंक इस प्रकार है

यह भी लगता है कि कार्यक्षेत्र अलग-अलग ग्रहण संस्करणों के बीच आवश्यक रूप से संगत नहीं हैं। यह आलेख बताता है कि आप अपने कार्यक्षेत्रों का नाम ग्रहण संस्करण के नाम से रखते हैं।

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

मुझे लगता है कि इसका उपयोग करने का एक अच्छा तरीका है

(वास्तव में, जैसा कि मैं यह लिख रहा हूं, मुझे नहीं पता कि इसे कैसे अच्छे तरीके से इस्तेमाल किया जाए, इसीलिए मैं इसका जवाब तलाश रहा था - कि मैं यहां इकट्ठा होने की कोशिश कर रहा हूं)

  1. अपनी परियोजनाओं के लिए एक फ़ोल्डर बनाएँ:
    /projects

  2. प्रत्येक प्रोजेक्ट के लिए एक फोल्डर बनाएं और प्रोजेक्ट्स की उप-परियोजनाओं को उसके अंदर समूहित करें:
    /projects/proj1/subproj1_1
    /projects/proj1/subproj1_2
    /projects/proj2/subproj2_1

  3. अपने कार्यक्षेत्र के लिए एक अलग फ़ोल्डर बनाएँ:
    /eclipse-workspaces

  4. अपनी परियोजनाओं के लिए कार्यस्थान बनाएँ:
    /eclipse-workspaces/proj1
    /eclipse-workspaces/proj2


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

2
यह उत्तर पूरे प्रश्न में योगदान देता है। हालाँकि, यह थोड़ा सा फ़ोकस है और कुछ संदर्भों और तर्कों को भी याद करता है। बहरहाल, यह जानकारीपूर्ण है। आह, ये उत्तर मुश्किल हो रहे हैं क्योंकि उनमें से सभी का योगदान है, और मुझे लगता है कि मैं एक उत्तर को स्वीकार करने में कभी सक्षम नहीं होऊंगा। मुझे आशा है कि कोई भी यहां एक बिंदु सनकी नहीं है और हम इसे बिना किसी स्वीकृत उत्तर के छोड़ देंगे?
ई-प्रेरक

अरे @ आरयू-बीएन। मैं बिंदु के लिए नहीं हूँ। मैं बस इच्छा करता हूं कि मैं समझा सकता हूं कि एक ग्रहण कार्यक्षेत्र क्या है, इसलिए मुझे यकीन है कि मैं इसे जानता हूं।
राफेल Eyng

अरे, मेरा मतलब यह नहीं था कि विशेष रूप से किसी के प्रति आखिरी सवाल। यह सिर्फ सामान्य तौर पर था। शायद मुझे इसे शीर्ष पर टिप्पणी के रूप में लिखना चाहिए था।
ई-प्रेरक

@ आरयू-बीएन, बिल्कुल, मैंने इसे खराब तरीके से नहीं लिया। शायद मैंने खुद को बुरी तरह से व्यक्त किया है।
राफेल Eyng

37

एक कार्यक्षेत्र का पूरा बिंदु संबंधित परियोजनाओं के एक समूह को एक साथ समूहित करना है जो आमतौर पर एक आवेदन करते हैं। कार्यक्षेत्र रूपरेखा eclipse.core.resourcesप्लगइन के लिए नीचे आता है और यह स्वाभाविक रूप से डिजाइन से समझ में आता है।

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

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


1
लेकिन आपके उत्तर के लिए धन्यवाद। यह समझ में आता है और कम से कम मुझे पता है कि इसका क्या मतलब है। क्या आप मुझे अपने पहले वाक्य के बारे में अधिक जानकारी और संभवतः एक लिंक (ग्रहण करने के लिए) दे सकते हैं?
ई-मोटिव

5
मैं असहमत हूं कि "एक कार्यक्षेत्र का बिंदु संबंधित परियोजनाओं के एक समूह को एक साथ समूहित करना है जो आमतौर पर एक आवेदन करते हैं।" मान लीजिए मैं दो एप्लिकेशन विकसित कर रहा हूं, क्या मुझे दो कार्यस्थान चाहिए? कैसा कष्टकर! सभी कस्टम दृष्टिकोण, कुंजी बाइंडिंग, ऑटो-टेक्स्ट और अन्य प्राथमिकताएं कार्यक्षेत्र से जुड़ी हुई हैं। जब भी मैं एक नया आवेदन शुरू करता हूं, मुझे उन्हें हर बार फिर से बनाना होगा! मेरी राय में, आपके पास दो कार्यक्षेत्र होने चाहिए: देव और नवीनतम जारी। कार्यक्षेत्र के भीतर, आप प्रत्येक अनुप्रयोग के लिए एक काम सेट बनाएँ। इस तरह से कार्यक्षेत्र और कामकाजी सेट का उपयोग किया जाना है।
जॉन हेनकेल

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

1
दिलचस्प बात @JohnHenckel! हालांकि मुझे काम करने के सेट से अपनी परेशानी थी। ऐसा लगता है कि वे केवल ग्रहण की कुछ विशेषताओं के साथ काम करते हैं, हालांकि मुझे लगता है कि आप उन सभी को मैन्युअल रूप से सेट कर सकते हैं (जैसा कि मैंने कल कार्यों को देखा था, जिसने मुझे सभी परियोजनाओं से अल टास्क दिया था)। क्या आप लाइब्रेरी के कार्यों, ऑटो-कम्पलीट, मौजूदा तरीकों आदि के लिए भी ऐसा कर सकते हैं? मुझे और रुचि है कि आप वर्किंग सेट का उपयोग कैसे करते हैं। @DuncanKrebs, मैं वरीयताओं के आयात / निर्यात सुविधा को नहीं जानता था। धन्यवाद! यह कार्यक्षेत्रों का उपयोग करने के एक बड़े सौदे को हल करता है। आप दोनों को शुक्रिया। और तर्क / अंतर्दृष्टि में फेंकने के लिए मत रोको!
ई-प्रेरक

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

3

मूल रूप से कार्यक्षेत्र (एस) का दायरा दो बिंदुओं में विभाजित है।

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

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

व्यक्तिगत रूप से, मैंने अपने आप को भाषा भेद के लिए अधिक दुबला पाया जब यह अलग-अलग कार्यस्थानों के लिए आता है जो कि ज्ञात मुद्दों के लिए प्रासंगिक है जो प्लगइन्स की वर्तमान स्थिति के साथ आता है। अधिमानतः मैं उन्हें न्यूनतम संख्या में रखता हूं क्योंकि यह कम निराशा की ओर जाता है जब परियोजनाएं बन जाती हैं ... बहुत सारे और संस्करण नियंत्रण एकमात्र संस्करण नहीं है जो आप अपनी परियोजनाओं को रखते हैं। अंत में, लोडिंग गति और प्रदर्शन एक ऐसा मुद्दा है जो अप्रासंगिक परियोजनाओं के प्रस्तुत होने के कारण बहुत सारे (अनावश्यक) प्लग इन लोड होने पर हो सकता है। जमीनी स्तर; हर एक के लिए कोई एक समाधान नहीं है, कोई भी मास्टर ब्लू प्रिंट जो इस मुद्दे को हल नहीं करता है। यह ऐसा कुछ है जो अनुभव के साथ बढ़ता है, कम हालांकि अधिक है!


DTLK से आपका क्या अभिप्राय है?

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

1

हालांकि मैंने वर्षों से ग्रहण का उपयोग किया है, यह "उत्तर" केवल अनुमान है (जो मैं आज रात की कोशिश करने जा रहा हूं)। अगर यह अस्तित्व से बाहर हो जाता है, तो जाहिर है कि मैं गलत हूं।

Oracle अपने MySQL कनेक्टर C स्रोत कोड के लिए Visual Studio "समाधान" जनरेट करने के लिए CMake पर निर्भर करता है। समाधान के भीतर "परियोजनाएं" हैं जिन्हें व्यक्तिगत रूप से या सामूहिक रूप से (समाधान द्वारा) संकलित किया जा सकता है। प्रत्येक प्रोजेक्ट का अपना स्वयं का मेकफाइल होता है, जो सॉल्यूशन के अपने हिस्से को उन सेटिंग्स के साथ संकलित करता है जो अन्य प्रोजेक्ट्स से अलग हैं।

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

इसलिए मैं वर्कस्पेस का उपयोग करने के लिए एक अच्छे तरीके की उम्मीद कर रहा हूं, यह है कि विज़ुअल स्टूडियो की एक समाधान में असंतुष्ट परियोजनाओं को संयोजित करने की क्षमता का अनुकरण करें ।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.