.classpath और .project - संस्करण नियंत्रण में जांचें या नहीं?

Question

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

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

Answer 1

निश्चित हाँ, जैसा कि मैंने "Do you keep your project files under version control?"

में कहा "इसे लोड करें, इसे सेट करें, जाओ।"

लेकिन ... यह वास्तव में केवल हाल Eclipse3.5 सेटिंग्स, संबंधित पथ जहां पथ समर्थन निर्माण के लिए सच है:

---

और Eclipse3.6 बेहतर होगा , क्योंकि यह पथ चर के लिए सापेक्ष पथ का समर्थन करता हैLinked Resources में:

(3 के बाद से।6M5)

Answer 2

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

Answer 3

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

यदि फ़ाइलों को इस तरह से चेक किया जाता है कि परियोजना खरोंच से चलती है तो उन्हें बदलने के लिए बहुत अधिक बल नहीं होना चाहिए।

Answer 4

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

यदि फ़ाइलों में पूर्ण पथ और समान हैं, तो एक README बेहतर विकल्प होगा।

Answer 5

हां, निश्चित रूप से इन्हें जांचें, लेकिन सुनिश्चित करें कि आप किसी भी पथ निर्भरता को दस्तावेज करते हैं और यदि संभव हो तो पूर्ण पथ से बचें।

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

कुछ बहुत जटिल व्यवस्था बेहतर एक स्क्रिप्ट के द्वारा नियंत्रित किया जा सकता है इन फ़ाइलों को उत्पन्न करने के लिए है, लेकिन आम तौर पर यह बेहतर है बस में उन्हें जांच करने के लिए।

Answer 6

मुझे कोई वोट है, लेकिन है कि क्योंकि मैं आम तौर पर मेरे अनुभव में Maven

Answer 7

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

<classpathentry kind="con" 
     path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/> 

अपने Mac पर

तो: दुर्भाग्य से, ग्रहण अक्सर बातें इस तरह .classpath में होना का कारण बनता है।

इसके अलावा, इसके आसपास कोई आसान तरीका नहीं है। ग्रहण हमेशा उसमें जोड़ देगा। मैं वहां .classpath फ़ाइल रखना चाहता हूं, क्योंकि हमारे lib फ़ोल्डर में कुछ तृतीय पक्ष JAR हैं जहां हम संस्करण के बारे में परवाह करते हैं, इसलिए हम उन्हें वहां छोड़ देते हैं ताकि नए डेवलपर उन्हें प्राप्त न करें । हम एक प्रबंधित सिस्टम में जा रहे हैं, लेकिन अभी भी प्रबंधित + अप्रबंधित निर्भरताओं की जांच की गई है। इसका मतलब है कि सभी डेवलपर्स को यह सुनिश्चित करना होगा कि दो निर्देशिकाएं .classpath एस में हैं। लेकिन हर बार जब आप खींचते हैं तो अपने जेआरई को ठीक करने से बेहतर होता है और आपके द्वारा किए जाने वाले हर बार अपने क्लासपाथ में बदलाव होता है।

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

तो मैं कहता हूँ: .settings निर्देशिका (* .prefs को छोड़कर) लांच कॉन्फ़िगरेशन के लिए स्रोत नियंत्रण में चला जाता है

.classpath बाहर रहता है

.project में चला जाता है