META-INF का उद्देश्य क्या है?

298

जावा में, आप अक्सर कुछ मेटा फ़ाइलों से युक्त META-INF फ़ोल्डर देखते हैं। इस फ़ोल्डर का उद्देश्य क्या है और मैं वहां क्या डाल सकता हूं?

java meta-inf

— क्रिस्टियन
स्रोत

13

मैनिफेस्ट फ़ाइलों के साथ काम करना: मूल बातें

— rmaruszewski

65

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

<jar ...>
    <manifest>
        <attribute name="Main-Class" value="MyApplication"/>
    </manifest>
</jar>

कम से कम, मुझे लगता है कि यह आसान है ... :-)

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

— डैनियल स्पाइवाक
स्रोत

17

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

— एरिक्सन

13

यदि आप JPA का उपयोग कर रहे हैं तो आपको उस फ़ोल्डर में एक persistence.xml डालना चाहिए, यह कुछ ऐसा है जो स्वचालित रूप से नहीं होता है।

— JRSofty

4

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

— जॉन लॉकवुड

क्या आप हमें इस फ़ोल्डर के प्रकारों के बारे में कुछ उदाहरण दे सकते हैं?

— मेनाई अला एडडिन - अलादीन

3

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

— क्रौव

164

से आधिकारिक JAR फ़ाइल विशिष्टता (लिंक जावा 7 संस्करण के लिए चला जाता है, लेकिन कम से कम पाठ v1.3 पर के बाद से नहीं बदला है):

मेटा-इन निर्देशिका

META-INF निर्देशिका में निम्नलिखित फाइलें / निर्देशिकाएं अनुप्रयोगों, एक्सटेंशन, क्लास लोडर और सेवाओं को कॉन्फ़िगर करने के लिए जावा 2 प्लेटफॉर्म द्वारा पहचानी और व्याख्या की जाती हैं:

MANIFEST.MF

विस्तार और पैकेज संबंधित डेटा को परिभाषित करने के लिए उपयोग की जाने वाली मैनिफ़ेस्ट फ़ाइल।

INDEX.LIST

यह फ़ाइल -iजार टूल के नए " " विकल्प से उत्पन्न होती है , जिसमें एप्लिकेशन या एक्सटेंशन में परिभाषित पैकेजों के लिए स्थान की जानकारी होती है। यह JarIndex कार्यान्वयन का हिस्सा है और इसका उपयोग क्लास लोडर द्वारा अपनी क्लास लोडिंग प्रक्रिया को तेज करने के लिए किया जाता है।

x.SF

JAR फ़ाइल के लिए हस्ताक्षर फ़ाइल। 'x' का आधार फ़ाइल नाम है।

x.DSA

एक ही आधार फ़ाइल नाम के साथ हस्ताक्षर फ़ाइल से जुड़ी हस्ताक्षर ब्लॉक फ़ाइल। यह फ़ाइल संबंधित हस्ताक्षर फ़ाइल के डिजिटल हस्ताक्षर को संग्रहीत करती है।

services/

यह निर्देशिका सभी सेवा प्रदाता कॉन्फ़िगरेशन फ़ाइलों को संग्रहीत करती है।

— अकु
स्रोत

3

TLD को META-INF के तहत भी जाना चाहिए।

— ई.पू. 24:08

@ हिरासन, विस्तृत?

— पेसियर

JSP टैग लाइब्रेरी के लिए @Pacerier टैग लाइब्रेरी डिस्क्रिप्टर META-INF निर्देशिका में स्थित होना चाहिए। मैं भूल गया था कि TLD 2008 में वापस किस लिए खड़ा था।

— एरिकसन

27

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

<import resource="classpath:/META-INF/cxf/cxf.xml" />
<import resource="classpath:/META-INF/cxf/cxf-extensions-*.xml" />

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

जब मैं इस निर्णय पर विचार करता हूं, तो मुझे नहीं पता कि वास्तव में META-INF के बजाय एक विशिष्ट जावा पैकेज में कॉन्फ़िगरेशन फ़ाइलों को शामिल करने में क्या गलत होगा। लेकिन यह एक उभरता हुआ वास्तविक मानक प्रतीत होता है; या तो, या एक उभरते विरोधी पैटर्न :-)

— user38748
स्रोत

4

कॉन्फिगरेशन एक लाइब्रेरी में नहीं है। मुझे लगता है कि आपने इसे "उभरते विरोधी पैटर्न" के साथ जोड़ा। लाइब्रेरी के सापेक्ष कॉन्फ़िगरेशन फ़ाइलों का पता लगाना वास्तव में बहुत आसान है; वे शारीरिक रूप से उसी JAR में जाने की जरूरत नहीं है जो पाया जाए।

— एरिक्सन

24

मैं इस कथन से सहमत नहीं हूं कि कॉन्फ़िगरेशन किसी लाइब्रेरी में नहीं है। मुझे लगता है कि विन्यास, खासकर जब यह चूक की बात आती है, एक पुस्तकालय में ठीक से पैक किया जाता है। मुझे वास्तव में खुशी है कि इस तरह के काम करने के लिए और अधिक रूपरेखाएँ चुनी गईं, क्योंकि आप सभी प्रकार की बाहरी कॉन्फ़िगरेशन फ़ाइलों को शामिल करने के लिए मजबूर कर रहे थे जैसे कि बहुत पहले नहीं था।

— ईलको

1

मैं बहुत सारी LICENSE.TXT प्रकार की फ़ाइलों को META_INF में दिखा रहा हूं, साथ ही, जो मुझे कष्टप्रद लगता है।

— टीआई स्ट्रगा

@ ईलको, कोड और डेटा को नहीं मिलाना चाहिए । बाहरी कॉन्फ़िगरेशन फ़ाइलों को शामिल करना आवश्यक नहीं है, इसका मतलब यह है कि एक गड़बड़ी गड़बड़ है। यह इस बात पर निर्भर करता है कि यह कैसे संरचित है।

— पचेरियर

1

यह @Pacerier को बताने के लिए एक बहुत ही मनमानी है। एक सामान्य कथन के रूप में, यह काफी हद तक प्राथमिकता है।

— इलको

13

META-INF फ़ोल्डर MANIFEST.MF फ़ाइल का घर है । इस फ़ाइल में JAR की सामग्री के बारे में मेटा डेटा है। उदाहरण के लिए, एक प्रविष्टि है जिसे मेन-क्लास कहा जाता है जो निष्पादन योग्य JAR फ़ाइलों के लिए स्थैतिक मुख्य () के साथ जावा वर्ग का नाम निर्दिष्ट करता है।

— ब्रायन मैथ्यूज
स्रोत

10

आप वहां स्थैतिक संसाधन भी रख सकते हैं।

उदाहरण में:

META-INF/resources/button.jpg

और के माध्यम से web3.0 कंटेनर में उन्हें मिलता है

http://localhost/myapp/button.jpg

> और पढ़ें

/META-INF/MANIFEST.MF का एक विशेष अर्थ है:

यदि आप जार का उपयोग करते हैं java -jar myjar.jar org.myserver.MyMainClassतो आप मुख्य वर्ग की परिभाषा को जार में ले जा सकते हैं ताकि आप कॉल को सिकोड़ सकें java -jar myjar.jar।
यदि आप उपयोग करते हैं तो आप Metainformations को संकुल में परिभाषित कर सकते हैं java.lang.Package.getPackage("org.myserver").getImplementationTitle()।
आप उन डिजिटल प्रमाणपत्रों का संदर्भ ले सकते हैं जिन्हें आप एप्लेट / वेबस्टार्ट मोड में उपयोग करना चाहते हैं।

— विकट
स्रोत

तो आवेदन में किसी भी स्थिर सामान को इस निर्देशिका में छवियों या अन्य सामान की तरह रखा जाना चाहिए।

— मेनाई अला एडडिन - अलादीन

6

मावेन में मेटा-इन

मेंवेन- इन फोल्डर को मानक निर्देशिका लेआउट के कारण समझा जाता है , जो कि कन्वेंशन पैकेज के नाम से JAR के भीतर आपके प्रोजेक्ट संसाधनों को पैकेज करता है: कोई भी निर्देशिका या फाइल जो $ {आधारित है / src / main / main / resource डायरेक्टरी में आपके JAR में पैक की जाती है। JAR के आधार पर शुरू होने वाली सटीक संरचना के साथ। फ़ोल्डर $ {आधारित /} / src / main / Resources / META-INF में आमतौर पर .properties फाइलें होती हैं, जबकि जार में एक उत्पन्न MANIFEST.MF , pom.properties , pom.xml , सहित अन्य फाइलें होती हैं। वेब संसाधनों की सेवा के लिए स्प्रिंग जैसे ढांचे का भी उपयोग किया classpath:/META-INF/resources/जाता है। अधिक जानकारी के लिए देखेंमैं अपने मावेन प्रोजेक्ट में संसाधनों को कैसे जोड़ूं ।

— EliuX
स्रोत

5

WAR फ़ाइल के मामले में, यहाँ जानकारी को जोड़ने के लिए, META-INF / MANIFEST.MF फ़ाइल डेवलपर को कंटेनर द्वारा एक नियत समय जाँच आरंभ करने की सुविधा प्रदान करती है जो यह सुनिश्चित करता है कि कंटेनर आपके सभी एप्लिकेशनों को ढूंढ सकता है निर्भर करता है। यह सुनिश्चित करता है कि यदि आपने एक JAR को याद किया है, तो आपको तब तक इंतजार नहीं करना होगा जब तक कि आपके आवेदन को यह न पता हो कि यह गायब है।

— ससुके
स्रोत

5

मैं इस मुद्दे पर हाल ही में सोच रहा हूं। वास्तव में META-INF के उपयोग पर कोई प्रतिबंध नहीं लगता है। निश्चित रूप से, कुछ सख्त हैं, जाहिर तौर पर वहाँ प्रकट करने की आवश्यकता के बारे में, लेकिन वहाँ किसी भी सामान को रखने के बारे में कोई निषेध नहीं है।

यह एक केस क्यों है?

Cxf मामला वैध हो सकता है। यहां एक और जगह है जहां इस गैर-मानक को JBoss-ws में एक बुरा बग के आसपास पाने की सिफारिश की गई है जो एक wsdl के स्कीमा के खिलाफ सर्वर-साइड सत्यापन को रोकता है।

http://community.jboss.org/message/570377#570377

लेकिन वास्तव में कोई भी मानक, कोई तू-तू-मैं-मैं नहीं होता है। आमतौर पर इन चीजों को बहुत सख्ती से परिभाषित किया जाता है, लेकिन किसी कारण से, ऐसा लगता है कि यहां कोई मानक नहीं हैं। अजीब। ऐसा लगता है कि META-INF किसी भी आवश्यक कॉन्फ़िगरेशन के लिए एक ऐसा स्थान बन गया है जिसे आसानी से किसी अन्य तरीके से नियंत्रित नहीं किया जा सकता है।

— स्टीव कोहेन
स्रोत

5

यहां जानकारी में जोड़ना, META-INF एक विशेष फ़ोल्डर है जो ClassLoaderजार में अन्य फ़ोल्डरों से अलग तरह से व्यवहार करता है। META-INF फ़ोल्डर के अंदर नेस्टेड तत्वों को इसके बाहर के तत्वों के साथ नहीं मिलाया जाता है।

इसे दूसरी जड़ की तरह समझें। से Enumerator<URL> ClassLoader#getSystemResources(String path)विधि एट अल परिप्रेक्ष्य:

जब दिया गया पथ "META-INF" से शुरू होता है, तो विधि उन संसाधनों की खोज करती है जो वर्ग पथ में सभी जार के META-INF फ़ोल्डरों के अंदर होते हैं।

जब दिया गया पथ "META-INF" से प्रारंभ नहीं होता है, तो विधि वर्ग पथ के सभी जार और निर्देशिकाओं के सभी अन्य फ़ोल्डरों (META-INF के बाहर) में संसाधनों की खोज करती है।

यदि आप किसी अन्य फ़ोल्डर नाम के बारे में जानते हैं जो getSystemResourcesविधि विशेष रूप से व्यवहार करती है, तो कृपया इसके बारे में टिप्पणी करें।

— Readren
स्रोत

3

यदि आप JPA1 का उपयोग कर रहे हैं, तो आपको persistence.xmlवहां एक फ़ाइल छोड़नी पड़ सकती है जो एक दृढ़ता-इकाई का नाम निर्दिष्ट करती है जिसे आप उपयोग करना चाहते हैं। एक दृढ़ता-इकाई मेटाडेटा फ़ाइलों, और वर्गों के सेट को निर्दिष्ट करने का एक सुविधाजनक तरीका प्रदान करती है, और जार जिसमें सभी वर्गों को एक समूह में बनाए रखा जाना है।

import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;

// ...

EntityManagerFactory emf =
      Persistence.createEntityManagerFactory(persistenceUnitName);

यहाँ और देखें: http://www.datanucleus.org/products/datanucleus/jpa/emf.html

— f0ster
स्रोत

1

सभी उत्तर सही हैं। मेटा-इन के कई उद्देश्य हैं। इसके अलावा, यहां टॉमकैट कंटेनर का उपयोग करने के बारे में एक उदाहरण है।

टॉमकैट डॉक्टर पर जाएं और " मानक कार्यान्वयन> copyXML " विशेषता की जांच करें।

विवरण नीचे है।

यदि आप एक संदर्भ XML डिस्क्रिप्टर अनुप्रयोग के अंदर एम्बेडेड (/META-INF/context.xml पर स्थित) चाहते हैं तो सही पर सेट करें, जब एप्लिकेशन को तैनात किया गया हो तब होस्ट करने वाले xmlBase में कॉपी किया जाना चाहिए। बाद में शुरू होने पर, कॉपी किए गए संदर्भ एक्सएमएल डिस्क्रिप्टर का उपयोग किसी भी संदर्भ में प्राथमिकता के लिए किया जाएगा एक्सएमएल डिस्क्रिप्टर एप्लिकेशन के अंदर एम्बेडेड है, भले ही डिस्क्रिप्टर एप्लिकेशन के अंदर एम्बेडेड हो हाल ही में। झंडे का मूल्य असत्य की ओर जाता है। ध्यान दें कि यदि मालिक की होस्ट की XXML विशेषता गलत है या यदि स्वयं के होस्ट की CopyXML विशेषता सही है, तो इस विशेषता का कोई प्रभाव नहीं होगा।

— Tugrul
स्रोत

0

आपके पास META-INF फ़ोल्डर में MANIFEST.MF फ़ाइल है। आप वैकल्पिक या बाहरी निर्भरता को परिभाषित कर सकते हैं, जिसकी आपको पहुंच होनी चाहिए।

उदाहरण:

विचार करें कि आपने अपना ऐप और अपना कंटेनर तैनात किया है (रन टाइम पर) पता चला है कि आपके ऐप में लाइब्रेरी के नए संस्करण की आवश्यकता है जो कि लिबास फ़ोल्डर के अंदर नहीं है, उस स्थिति में यदि आपने वैकल्पिक नए संस्करण को परिभाषित किया है MANIFEST.MFतो आपका ऐप संदर्भित करेगा वहाँ से निर्भरता (और दुर्घटना नहीं होगी)।

Source: हेड फर्स्ट जेएसपी एंड सर्वलेट

— प्रतीक जोशी
स्रोत

1

यह स्पष्ट नहीं है कि यह स्रोत से कितना उद्धृत किया गया है, और यह शब्दशः नहीं दिखता है। निकाले गए विचित्र स्वरूपण। पाठ के लिए कोड फ़ॉर्मेटिंग का उपयोग न करें जो कोड नहीं है। पाठ के लिए उद्धरण प्रारूप का उपयोग करें जो उद्धृत है।

— लोरेन का