Відповіді:
Взагалі кажучи, ви нічого не повинні вводити в META-INF. Натомість вам слід покластися на все, що ви використовуєте для упаковки свого JAR. Це одна з областей, на якій я думаю, що Ant дійсно перевершує: вказівку атрибутів явного файлу JAR. Дуже легко сказати щось на кшталт:
<jar ...>
<manifest>
<attribute name="Main-Class" value="MyApplication"/>
</manifest>
</jar>Принаймні, я думаю, що це просто ... :-)
Справа в тому, що META-INF слід вважати внутрішнім мета- каталогом Java . Не возиться з цим! Будь-які файли, які ви хочете включити до свого JAR, слід розмістити в іншому під-каталозі або в корені самого JAR.
З офіційної специфікації файлу JAR (посилання переходить до версії Java 7, але текст не змінювався щонайменше v1.3):
Каталог META-INF
Наступні файли / каталоги в каталозі META-INF розпізнаються та інтерпретуються платформою Java 2 для налаштування програм, розширень, навантажувачів класів та служб:
MANIFEST.MFФайл маніфесту, який використовується для визначення даних про розширення та пакети.
INDEX.LISTЦей файл генерується новою
-iопцією інструменту jar, яка "" містить інформацію про місцезнаходження для пакетів, визначених у програмі чи розширенні. Він є частиною реалізації JarIndex і використовується навантажувачами класів для прискорення процесу завантаження класів.
x.SFФайл підпису для файлу JAR. 'x' позначає ім'я базового файлу.
x.DSAФайл блоку підписів, пов'язаний з файлом підпису з тим самим базовим файлом. Цей файл зберігає цифровий підпис відповідного файла підпису.
services/У цьому каталозі зберігаються всі файли конфігурації постачальника послуг.
Я помітив, що деякі бібліотеки Java почали використовувати META-INF як каталог, в який включати файли конфігурації, які повинні бути упаковані та включені в CLASSPATH разом з JAR. Наприклад, Spring дозволяє імпортувати XML-файли, які перебувають на шляху до класу за допомогою:
<import resource="classpath:/META-INF/cxf/cxf.xml" />
<import resource="classpath:/META-INF/cxf/cxf-extensions-*.xml" />У цьому прикладі я цитую прямо з Посібника користувача Apache CXF . У проекті, над яким я працював, в якому нам довелося дозволити декілька рівнів конфігурації через Spring, ми дотримувалися цієї конвенції і помістили наші файли конфігурації в META-INF.
Коли я розмірковую над цим рішенням, я не знаю, що саме було б не так, просто включивши файли конфігурації в конкретний пакет Java, а не в META-INF. Але це, здається, є новим фактичним стандартом; або це, або новий анти-шаблон :-)
Папка META-INF - це головна для файлу MANIFEST.MF . Цей файл містить метадані про вміст JAR. Наприклад, є запис під назвою Main-Class, який визначає ім'я класу Java зі статичним main () для виконуваних файлів JAR.
Ви також можете розмістити там статичні ресурси.
Наприклад:
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.java.lang.Package.getPackage("org.myserver").getImplementationTitle().У Maven папка META-INF розуміється через стандартний макет каталогів , який за конвенцією імен пакує ваші ресурси проекту в межах JAR: будь-які каталоги або файли, розміщені в каталозі $ {basedir} / src / main / ресурси , пакуються у ваш JAR з точно такою ж структурою, що починається в основі JAR. Папка $ {basedir} / src / main / ресурси / META-INF зазвичай містить файли .properties, тоді як в банку міститься створене MANIFEST.MF , pom.properties , pom.xml , серед інших файлів. Також такі структури, як Spring, використовуються classpath:/META-INF/resources/для обслуговування веб-ресурсів. Для отримання додаткової інформації дивЯк додати ресурси до свого проекту Maven .
Просто для додання тут інформації, у випадку файлу WAR, файл META-INF / MANIFEST.MF надає розробнику можливість ініціювати перевірку часу розгортання контейнером, що гарантує, що контейнер може знайти всі класи вашої програми залежить від. Це гарантує, що у випадку, якщо ви пропустили JAR, вам не доведеться чекати, поки ваша програма почне виконуватись, щоб зрозуміти, що вона відсутня.
Я недавно думав над цим питанням. Звичайно, не існує обмежень щодо використання META-INF. Звичайно, існують певні суворі вимоги щодо необхідності розміщення маніфесту, але, як видається, немає ніяких заборон щодо розміщення інших матеріалів.
Чому це так?
Справа cxf може бути законною. Ось ще одне місце, де цей нестандартний рекомендується обійти неприємну помилку в JBoss-ws, яка перешкоджає валідації на стороні сервера щодо схеми wsdl.
http://community.jboss.org/message/570377#570377
Але насправді, здається, немає жодних стандартів, будь-яких тисячоліть. Зазвичай ці речі дуже чітко визначені, але чомусь, здається, тут немає стандартів. Незвичайно. Схоже, що META-INF став місцем вибору для будь-якої необхідної конфігурації, яку неможливо легко обробити іншим способом.
Додаючи сюди інформацію, META-INF - це спеціальна папка, яка ClassLoaderрозглядає інакше, ніж інші папки в банку. Елементи, вкладені всередині папки META-INF, не змішуються з елементами поза нею.
Подумайте про це як про інший корінь. З Enumerator<URL> ClassLoader#getSystemResources(String path)точки зору методу та інших:
Коли даний шлях починається з "META-INF", метод здійснює пошук ресурсів, які вкладені всередині папок META-INF у всіх банках шляху до класу.
Коли даний шлях не починається з "META-INF", метод шукає ресурси у всіх інших папках (за межами META-INF) усіх банок та каталогів у шляху до класу.
Якщо ви знаєте про інше ім'я папки, яке getSystemResourcesметод спеціально стосується, будь ласка, прокоментуйте це.
Якщо ви використовуєте 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
Усі відповіді правильні. Мета-інф має багато цілей. Крім того, ось приклад використання контейнера tomcat.
Перейдіть у Tomcat Doc і перевірте атрибут " Стандартна реалізація> copyXML ".
Опис нижче.
Установіть значення true, якщо ви хочете, щоб контекстний дескриптор XML, вбудований всередину програми (розташований за адресою /META-INF/context.xml), був скопійований у власний xmlBase хоста при розгортанні програми. При наступних запусках скопійований дескриптор XML контексту буде використовуватися в перевазі будь-якого контекстного дескриптора XML, вбудованого всередину програми, навіть якщо дескриптор, вбудований всередину програми, більш сучасний. Значення прапора за замовчуванням відповідає значенням false. Зверніть увагу, якщо атрибут розміщенняXML власного хоста хибний або якщо атрибут copyXML власного хоста є істинним, цей атрибут не матиме ефекту.
Ви маєте файл MANIFEST.MF у папці META-INF. Ви можете визначити факультативні або зовнішні залежності , до яких потрібно мати доступ.
Приклад:
Подумайте, що ви розгорнули додаток, і ваш контейнер (під час запуску) з’ясував, що для вашої програми потрібна нова версія бібліотеки, яка не знаходиться в папці lib, у цьому випадку, якщо ви визначили необов’язковішу нову версію, MANIFEST.MFтоді ваш додаток буде посилатися до залежності відвідти (і не впаде).
Source: Головний перший Jsp & Servlet