2009-07-04 13 views
15

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

मेरा लक्ष्य एक मॉड्यूल लेना है जिसे मैंने लिखा है और इसे ओपन सोर्स के रूप में प्रकाशित किया है।

संपादित करें - मुझे अभी भी ज़िप फ़ाइल में क्या होना चाहिए, इसके बारे में प्रत्यक्ष, ठोस निर्देश याद आ रहे हैं। क्या इसके लिए सम्मेलन हैं, या क्या मुझे कुछ उचित संरचना चुननी चाहिए?

उत्तर

6

कार्ल फोगेल की पुस्तक http://producingoss.com/ - ऑनलाइन उपलब्ध स्रोत देखें।

+0

पुस्तक अच्छी लगती है। धन्यवाद। क्या आपने इसे मुफ्त ऑनलाइन पुस्तकों (अन्य प्रश्न) की सूची में भी पोस्ट किया है –

7

मुझे यकीन है कि अगर वहाँ "सर्वोत्तम प्रथाओं" पर सार्वभौमिक समझौता हो जाएगा नहीं कर रहा हूँ, लेकिन आइटम आप का उल्लेख आसान जवाब हो सकता है:

  1. वितरण java.net या Sourceforge साथ आसान है। आप अपने मानकों का उपयोग करके अपना कोड प्रकाशित करेंगे,
  2. पैकेजिंग ज़िप फ़ाइलें होगी। ग्राहकों के लिए उनके डाउनलोड की अखंडता की जांच करना संभव बनाने के लिए एमडी 5 हैश बनाने का अच्छा विचार है।
  3. प्रलेखन - हाँ, बहुत कृपया। अलग javadocs और एक संदर्भ गाइड है जो दिखाता है कि अपनी सामग्री का उपयोग कैसे करें।
  4. एक सार्वजनिक एसवीएन है जो अज्ञात पहुंच की अनुमति देता है ताकि लोग अपने आप को नवीनतम कोड प्राप्त कर सकें।
  5. एक बग ट्रैकर है कि लोगों को कीड़े, नई सुविधाओं पर रिपोर्ट करने के लिए अनुमति देता है, आदि
  6. चर्चा, प्रतिक्रिया के लिए एक विकि सेट करें, आदि
  7. Maven एक खुला स्रोत मानक के बारे में कुछ बन गया है है। उन साहसी लोगों के लिए एक अच्छा pom.xml है जो जांचना और अपना कोड बनाना चाहते हैं।
  8. यूनिट परीक्षण और अच्छी कोड कवरेज गुणवत्ता के प्रति आपकी वचनबद्धता को प्रदर्शित करने में मदद करेगा।

मैं और अधिक सोचने की कोशिश करूंगा।

+0

ज़िप फ़ाइल के अंदर निर्देशिका संरचना? इसे होस्ट करने के लिए सबसे अच्छी जगह क्या है? पसंदीदा रूप से, इसमें एकीकृत विकी, बगट्रैकर, बिल्ड सिस्टम और मुझे परेशानी बचाएगी ... – ripper234

+0

चूंकि यह जावा है, मुझे लगता है कि आपके पास मानक ईएआर या वार होगा। एक जेएआर लाइब्रेरी या डेस्कटॉप ऐप होगा। जब भी कोई ग्राहक आपके कोड को डाउनलोड और अनजिप करता है तो उस स्थिति में सही संरचना होती है। – duffymo

2

मुझे लगता है कि यह सब बिल्ड-टेस्ट-पैकेज-तैनाती चक्र को स्वचालित करने के लिए नीचे उबलता है। आदर्श रूप से, आपको इसे एक क्लिक (या एक ही प्रॉम्प्ट कमांड के साथ) करने में सक्षम होना चाहिए।

व्यक्तिगत रूप से, मैं चींटी का उपयोग करें और एक तैनाती लक्ष्य जो निम्नलिखित

  1. सभी कलाकृतियों एक भी प्रदेय में
  2. संकुल कलाकृतियों बनाता करता है (.zip फ़ाइल)
  3. को परिभाषित
  4. एक स्थानीय निर्देशिका
  5. में .zip कि स्थानीय निर्देशिका
  6. अपलोड से टेस्ट स्वीट चलाता unzips ज़िप sourceforge पर

ऐसा करने के बाद ही एकमात्र मैन्युअल चरण Sourceforge की वेब साइट के माध्यम से एक नई रिलीज को परिभाषित करना है।

जाहिर है, इस प्रक्रिया को प्रभावी बनाने के लिए आपको परीक्षण संक्रमित होना चाहिए - मैं लागू होने वाली हर नई सुविधा के लिए परीक्षण लिखता हूं।

+2

मुझे आश्चर्य है कि इसे वोट क्यों मिला - मुझे यह मेरे प्रश्न के लिए पूरी तरह से अप्रासंगिक लगता है। हां, स्वचालित तैनाती और परीक्षण अच्छा है - लेकिन मैं क्या तैनात करना है, निर्देशिका संरचना क्या होनी चाहिए, क्या दस्तावेज प्रदान करना है, आदि के बारे में पूछ रहा हूं ... तैनाती स्क्रिप्ट कैसे बनाएं। – ripper234

+1

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

4

यदि आप विशिष्ट निर्देशिका संरचनाओं की तलाश में हैं, तो मौजूदा ओपन सोर्स प्रोजेक्ट्स को क्यों न देखें? मैं Jakarta Commons से शुरू करूंगा, जो एक भारी उपयोग किया गया पैकेज है।

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

3

मुझे लगता है कि बहुत जोड़ने नहीं कर रहा हूँ, लेकिन मैं निम्नलिखित सुझाव है:

निर्देशिका संरचना

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

पैकेजिंग

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

प्रकाशन

  • यदि लागू हो अपने मॉड्यूल अपलोड करने के लिए निर्देशों का पालन करें।
  • अपने मॉड्यूल (ब्लॉग, मंच, ट्विटर, आदि)

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

1

अपनी परियोजना फू नाम दिया गया है, तो संस्करण XY फू-XYzip में पैक किया जाना चाहिए और फू-XY के अनज़िप/.... (दूसरे शब्दों में, संग्रह में प्रत्येक फ़ाइल का रास्ता चाहिए फू-एक्स के साथ शुरू करें।वाई /)

एक फू-एक्स.वाई/README.txt एक सादा पाठ फ़ाइल के रूप में बुनियादी निर्देश युक्त है। इसमें कम से कम जानकारी होनी चाहिए कि पूर्ण दस्तावेज कहां है ("दस्तावेज़ों के लिए दस्तावेज़/index.html देखें") के साथ-साथ उपयोग के बारे में संक्षिप्त निर्देश ("अपने क्लासपाथ में lib/foo-XYjar जोड़ें") और निर्देशों का पुनर्निर्माण करना चाहिए (" एपिडोक में lib और javadoc में पुस्तकालयों को पुन: उत्पन्न करने के लिए "चींटी निर्माण" चलाएं ")।

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

मैं सुझाव देता हूं कि स्रोत/स्रोत के तहत निर्मित पुस्तकालय, lib के तहत निर्मित पुस्तकालय/दस्तावेज़ों के तहत दस्तावेज/- यह वही है जो लोग उम्मीद करेंगे।

0

उपयोग Apache Maven 2 और के रूप में वे उपकरण की एक विस्तृत विविधता है कि आप सभी कलाकृतियों की जरूरत है ... एक साधारण आदेश "mvn पैकेज साइट"

0

मैं SourceForge (http://sourceforge.net) सुझाव है कि अपनी परियोजना की मेजबानी के लिए साथ मिल जाएगा (ब्लॉगिंग, विकी, स्रोत नियंत्रण विकल्प, आदि) और यह सब मुफ्त है।

जहां तक ​​ज़िप/जार में रखना है ... यह वास्तव में प्रोजेक्ट के प्रकार पर निर्भर करता है। यदि यह पुन: प्रयोज्य लाइब्रेरी है, तो मैं सुझाव दूंगा कि संग्रह की जड़ में, अपना लाइसेंस और अपना वितरण जार है। आप दस्तावेज़ों उपनिर्देशिका में अपने दस्तावेज़ के साथ, एक lib उप-निर्देशिका में निर्भरता डाल सकते हैं।

एक उदाहरण शायद आपको बेहतर मदद करेगा ... जकार्ता कॉमन्स - लैंग एपीआई (http://commons.apache.org/lang) डाउनलोड करें और देखें कि वे क्या प्रदान करते हैं।

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

शुभकामनाएं और मुझे आशा है कि इससे थोड़ा सा मदद मिलेगी।

+0

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

0

पुस्तक: Practical API Design Confessions of a Java Framework Architec टी (जारोस्लाव तुलाच, 2008, अप्रेस)।

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

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