2012-09-24 9 views
8

मैंने एक ग्रहण 4 एप्लिकेशन बनाया और मुझे jar की आवश्यकता है जो मेरे आवेदन के हिस्से के रूप में कार्यक्षमता प्रदान करता है (यह कुछ भी हो सकता है उदा। log4j इसे छोटा बनाने के लिए)।
मैंने अपने प्रोजेक्ट के क्लासपाथ (Right Click->Configure Build Path) के हिस्से के रूप में jar जोड़ा लेकिन रनटाइम पर मेरी सेवा ClassNotFound त्रुटि (ओएसजीआई अनुमान से?) के साथ विफल रही।
वैसे भी इसे खोजना, कम से कम जैसा कि मैंने इसे समझ लिया है, मुझे जार को Plugin के हिस्से के रूप में जोड़ना चाहिए और इस एप्लिकेशन को मेरे एप्लिकेशन/सेवा से निर्भरता बनाना चाहिए।
आईई। मैंने बनाया।
इस बार सेटअप काम किया।
तो अगर मैं इसे समझता हूं, ग्रहण/ओएसजीआई के लिए विकास करते समय हमें सीधे क्लासपाथ में jars जोड़ना नहीं चाहिए, लेकिन उन्हें प्लगइन्स (क्यों?) के माध्यम से जोड़ें।
प्रश्न: यदि मैं अभी तक सही हूं, तो परियोजना को विकसित करते समय jars को शामिल करने के लिए मानक अभ्यास क्या है?
परिभाषित करें/एक Plugin Project from existing JAR archives बनाएँ और जोड़ने सभी आवश्यक तृतीय पक्ष वहाँ की जरूरत पुस्तकालयों, या है प्रति एक अलग प्लगइन परियोजना की जरूरत jarया कुछ और शायद ???
क्षमा करें अगर मेरी शब्दावली सटीक नहीं है। मैं OSGi और ग्रहण प्रोग्रामिंगकिसी ग्रहण/osgi एप्लिकेशन से जार फ़ाइल पर निर्भरता कैसे शामिल करें?

नोट में नया हूँ: जब jars बारे में बात कर रहा अन्य OSGi सेवाओं की चर्चा करते हुए नहीं कर रहा हूँ। मैं तैयार, भरोसेमंद तृतीय पक्ष पुस्तकालयों का उपयोग करने के मानदंड का जिक्र कर रहा हूं जिसे किसी आवेदन के कई हिस्सों की आवश्यकता होगी। जैसे log4j या एक एक्सएमएल पार्सिंग लाइब्रेरी या apache commons आदि

+0

क्या अपने अंतिम लक्ष्य है: आप "अपने" परियोजना के लिए एक प्रदेय बनाने के लिए करना चाहते हैं, का कहना है कि एक जार/ज़िप जिसमें आपके प्रोग्राम को चलाने के लिए सभी आवश्यक कक्षाएं/जार/संसाधन हैं? – Kashyap

+0

@thekashyap: सुनिश्चित नहीं मैं समझता हूँ कि आपके सवाल का उत्पाद है, है ना निर्यात '.product' विन्यास द्वारा पूर्वनिर्धारित है तो मेरी चिंता का विषय कैसे परियोजना सेटअप होना चाहिए ताकि तैनाती में मुझे पता है कि कि सभी आवश्यक जार उपलब्ध हैं? । – Cratylus

+0

चेक आउट: http://www.vogella.com/articles/OSGi/article.html और http://www.coderanch.com/t/104274/vc/Order-Export-tab-Java-Build – Kashyap

उत्तर

3

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

ये निर्भरता आपके प्रोजेक्ट क्लासपाथ के अनुसार प्रकट होती है। एक ग्रहण प्लगइन परियोजना में, परियोजनाओं को वर्गपाथ का निर्माण मैनिफेस्ट में प्रविष्टियों से लिया गया है।

भले ही आप सेवाओं का उपयोग नहीं कर रहे हैं, फिर भी सभी कोड निर्भरताएं मैनिफेस्ट के माध्यम से बनाए रखी जाती हैं।

+0

लेकिन अगर मैं 'आयात पैकेज' का उपयोग करता हूं जिसका अर्थ है कि 'जार' कहीं भी 'ओएसजीआई' कंटेनर पर तैनाती पर सही है? तो मुझे कैसे पता चलेगा कि कौन से जार पहले से उपलब्ध हैं? उदा। मुझे कैसे पता चलेगा कि 'log4j' पहले ही पेश किया जा चुका है? और मैं 'अपाचे कॉमन्स' का उपयोग कैसे करूं? क्या यह पहले से ही शामिल है? यह कैसे संभव है? – Cratylus

+0

मेरा मतलब है कि ऐसे मामले हैं जिनके लिए मुझे कुछ जार की आवश्यकता होगी जो पहले ही बंडल के रूप में नहीं पेश की गई है, है ना? – Cratylus

+0

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

5

रनटाइम के लिए यह हमेशा प्रकट होता है और शीर्षलेख होता है जो आपके बंडल क्लासपाथ में नियंत्रण करता है। जार तक पहुंचने के तीन तरीके हैं:

  1. आयात-पैकेज शीर्षलेख। यह अनुशंसित तरीका है। आप प्रति पैकेज एक आयात को परिभाषित करते हैं जो आपको चाहिए। आप जिस जार को एक्सेस करना चाहते हैं उसे रनटाइम में बंडल के रूप में तैनात किया जाना है। इसे सभी आवश्यक पैकेजों को निर्यात करने की भी आवश्यकता है।

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

  3. बंडल-क्लासपाथ। यह आपके क्लासपाथ में जार जोड़ने की अनुमति देता है जिसे आप अपने बंडल में एम्बेड करते हैं। यह एक आखिरी उपाय होना चाहिए जब दूसरा तरीका काम न करे। अन्य विधियों के साथ मिश्रण करते समय आपको खराब वर्गीकरण समस्याएं हो सकती हैं।

आप मेवेन सेंट्रल में कई पूर्व निर्मित बंडल पा सकते हैं। आजकल कई जारों में ओएसजीआई मैनिफेस्ट है। उन मामलों के लिए जहां यह सच नहीं है कई जार servicemix द्वारा बंडलों के रूप में repackaged हैं। समूह आईडी देखें: org.apache.servicemix.bundles। वसंत बंडल भंडार भी है जहां आपको कुछ और मिलता है।

नीचे मैंने कुछ संसाधन को पढ़ने के लिए चाहते हो सकता है सूचीबद्ध:

http://www.aqute.biz/Blog/2007-02-19

http://wiki.osgi.org/wiki/Import-Package

http://wiki.osgi.org/wiki/Require-Bundle

http://www.vogella.com/blog/2009/03/27/required-bundle-import-package/

+0

मामले के लिए (1) अगर मुझे जरूरी जारों के लिए बंडल बनाने की ज़रूरत है, तो क्या मुझे इस बंडल में आवश्यक सभी * जारों को रखना चाहिए (यदि मुझे एक से अधिक की आवश्यकता है) ** या ** प्रत्येक जार प्रत्येक बंडल में होना चाहिए? – Cratylus

+0

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

3

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

Bundle-ClassPath: ., 

/lib/<legacy jar>.jar 

निर्यात और संकुल के आयात को अनावश्यक रूप से करता है, तो केवल एक ही बंडल यह उपभोग करने के लिए जा रहा है की कोई जरूरत नहीं है,

+2

+1 यह बंडल सामान एक असहनीय ओवरहेड जोड़ रहा है, खासकर जब समानांतर में जेएआर और ग्रहण प्लगइन विकसित करना। परेशान, और हर पुनरावृत्ति पर, यह समय खपत करता है, आप प्रवाह का निर्माण करते हैं ... मैं ** चमकदार मैवेन के लिए दृढ़ता से ग्रहण से नफरत करता हूं ** प्लगइन विकास प्रक्रिया का निर्माण करता हूं। हाँ, टाइको है, लेकिन मैं अपने ताजे कटे हुए हाथ से अपने सिर को तोड़ दूंगा, जब तक कि मैं उस गुप्त, अनियंत्रित बैंड सहायता का उपयोग करने से सहज महसूस न करूँ, जो कि ग्रहण प्लगइन विरासत के अंतराल वाले घाव के लिए डिज़ाइन किया गया है जार निर्भरता उपयोग। चुस्त, नहीं! – ppeterka