जावा प्रोजेक्ट: चाहिए .classpath .project फ़ाइल को भंडार में किया जाना चाहिए?

Question

क्या मुझे अपनी प्रोजेक्ट और .classpath फ़ाइलों में जांच करनी चाहिए?

मेरे दोस्त ने मुझे बताया कि मुझे पोर्टेबिलिटी की गारंटी के लिए केवल .java फ़ाइलों और build.xml में जांच करनी चाहिए। उन्होंने कहा ".classpath आपको विभिन्न पर्यावरण पर बहुत कम पोर्टेबिलिटी का कारण बन जाएगा। प्रोजेक्ट पूरी तरह से आपकी स्थानीय ग्रहण सेटिंग है"

मैं उनके साथ सहमत हूं, लेकिन आंशिक रूप से।

- .project फ़ाइल में जाँच नहीं मेरे विकास कम कुशल कर देगा (मैं नहीं बस "आयात" एक निर्देशिका से एक परियोजना कोड कर सकते हैं)

- .classpath फ़ाइल में जाँच नहीं मेरे लिए ठीक लगता है (?) अगर मेरा build.xml ध्यान से लिखा है।

कोई भी यहां अपना अनुभव साझा करना चाहता है?

Answer 1

.project और .classpath में जांच करने में कुछ भी गलत नहीं है। मैं ऐसा करूँगा, अगर आपका build.xml आपके लिए दोनों फाइलें बनाने में सक्षम नहीं है। जैसा कि आपने कहा था, जब आप एक नया ग्रहण कार्यक्षेत्र बनाने का प्रयास करते हैं तो इन फ़ाइलों को याद करने में असहज है।

.classpath में चेक करने से पहले आपको यह सुनिश्चित करना चाहिए कि इसमें कोई पूर्ण पथ न हो। एक पाठ संपादक के साथ इसे एक रिश्तेदार में कनवर्ट करें।

संपादित करें: या और भी बेहतर, @ टेलर-Leese टिप्पणी की तरह, अपने अन्यथा पूर्ण pathes में ग्रहण classpath चर का उपयोग करें।

Answer 2

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

Answer 3

.project फ़ाइल में जाँच नहीं मेरे विकास कम कुशल कर देगा (मैं नहीं बस "आयात" एक निर्देशिका से एक परियोजना कोड कर सकते हैं) इस समस्या के लिए

, आप चुन सकते हैं नई परियोजना बनाने के लिए और मौजूदा स्रोत आयात करें।

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

Answer 4

भंडारण में .classpath और .project फ़ाइलों को जांचने में कोई समस्या नहीं है। इससे डेवलपर्स की मदद मिलेगी जो एक्लिप्स का तेजी से आगे बढ़ने के लिए उपयोग करते हैं।

चेतावनी: सुनिश्चित करें कि आपकी .classpath फ़ाइल केवल कलाकृतियों का संदर्भ दे रही है जो या तो परियोजना के साथ भंडार में चेक की जाती है या स्वचालित रूप से प्राप्त की जा सकती है (जैसे मैवेन कलाकृतियों)।

Answer 5

मैं जांचना पसंद करूंगा। प्रोजेक्ट और .classpath।

यह प्रोजेक्ट एकाधिक डेवलपर्स द्वारा साझा किया जाने पर यह सहायक होगा। यह विकास एनवी स्थापित करने के लिए आसान और तेज़ हो जाता है। ग्रहण का उपयोग कर किसी भी सिस्टम पर इसे मौजूदा प्रोजेक्ट के रूप में आयात करके।

क्लासपाथ परियोजना के सापेक्ष केवल सावधानी बरतनी चाहिए।

Answer 6

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

जब आप वरीयताओं को साझा करते हैं, तो आप सुनिश्चित हैं कि हर कोई परियोजना (प्लगइन्स कॉन्फ़िगरेशन, एन्कोडिंग, प्रोफाइल [इंटेलिजे के लिए]] पर समान स्थितियों के साथ काम करेगा) जो वास्तव में एक अच्छी बात हो सकती है।

यह मुझे परेशान नहीं करता है जब कुछ ग्रहण फ़ाइलें यहाँ हैं, और मुझे लगता है कि यह वास्तव में अन्य डेवलपर्स परेशान नहीं करता है जब कुछ छिपी हुई फ़ाइलें सिर्फ वहाँ रखना नहीं करना चाहिए /।

Answer 7

हम जांच करते हैं। प्रोजेक्ट और .classpath। ProjectSet के साथ यह हमें एक भी "आयात दल ProjectSet"

Answer 8

ऐसे सभी फाइलों के साथ कुंजी सवाल है के साथ जटिल कार्यस्थानों की जाँच करने की अनुमति देता "वे स्वचालित रूप से reproduced जा सकता है?" यदि नहीं, तो उन्हें स्रोत नियंत्रण में जांचें।

इस मामले में, मैं कहना चाहता हूँ "हाँ," जब तक आप Maven, जो m2eclipse और ग्रहण उन्हें आप के लिए उत्पन्न करने के लिए प्लगइन है का उपयोग कर रहे हैं।

Answer 9

मेरे 2 सेंट के लिए, मैं इसे एक खराब अभ्यास के रूप में रेट करूंगा। परियोजनाओं को आईडीई से बंधे नहीं जाना चाहिए, और विशेष रूप से आईडीई के एक विशिष्ट संस्करण से बंधे नहीं होना चाहिए।

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

Answer 10

मुझे अक्सर समान, अधिक सामान्य पूछताछ होती है। समस्या अनिवार्य रूप से है:

• जो फ़ाइलों मैं मुझे के लिए करने से कर रहा हूँ?
• अन्य के लिए मैं कौन सी फाइलों का उपयोग कर रहा हूं?
• → मैं "संस्करण" के दोनों उद्देश्यों को कैसे जोड़ूं?

मैं इस there चर्चा करते हैं, तो आप समस्या के बारे में अधिक जानकारी प्राप्त कर सकते हैं दिलचस्प समाधान :)

---

एक मैं सबसे ज्यादा पसंद के साथ साथ, की पेशकश की git submodule का प्रयोग होता है: अपने .project फ़ाइलों को रखना एक निजी प्रतिबद्धता रेपो में आदि। और अपने अंतिम, शुद्ध, आवश्यक src उत्पादन को एक साफ submodule नगेट में बनाएं: एक सार्वजनिक रेपो।

project/ # root module 
| .git # private repo 
| .project 
| .classpath 
| momsNumber.txt 
+---src/  # submodule 
| | .git # public repo 
| | main.java 
| +---package/ 
| | | Etc.java 

---

See there anyway.