¿Cuál es el propósito de META-INF?

Desde la especificación oficial del archivo JAR (el enlace va a la versión Java 7, pero el texto no ha cambiado desde al menos v1.3):

El directorio META-INF

La plataforma Java 2 reconoce e interpreta los siguientes archivos/directorios en el directorio META-INF para configurar aplicaciones, extensiones, cargadores de clases y servicios:

• MANIFEST.MF

El archivo de manifiesto que se utiliza para definir la extensión y el paquete de datos relacionados.

• INDEX.LIST

Este archivo es generado por la nueva opción "-i" de la herramienta jar, que contiene información de ubicación para paquetes definidos en una aplicación o extensión. Forma parte de la implementación de JarIndex y la utilizan los cargadores de clases para acelerar su proceso de carga de clases.

• x.SF

El archivo de firma para el archivo JAR. 'x' significa el nombre del archivo base.

• x.DSA

El archivo de bloque de firma asociado con el archivo de firma con el mismo nombre de archivo base. Este archivo almacena la firma digital del archivo de firma correspondiente.

• services/

Este directorio almacena todos los archivos de configuración del proveedor de servicios.

Me he dado cuenta de que algunas bibliotecas de Java han empezado a usar META-INF como un directorio en el que se incluyen los archivos de configuración que se deben empaquetar e incluir en CLASSPATH junto con los JAR. Por ejemplo, Spring le permite importar archivos XML que están en la ruta de clase usando:

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

En este ejemplo, cito directamente de la Guía del usuario de Apache CXF . En un proyecto en el que trabajé en el que tuvimos que permitir múltiples niveles de configuración a través de Spring, seguimos esta convención y pusimos nuestros archivos de configuración en META-INF.

Cuando reflexiono sobre esta decisión, no sé qué sería exactamente incorrecto con la simple inclusión de los archivos de configuración en un paquete Java específico, en lugar de en META-INF. Pero parece ser un estándar de facto emergente; ya sea eso, o un anti-patrón emergente :-)

La carpeta META-INF es el hogar del archivo MANIFEST.MF . Este archivo contiene metadatos sobre el contenido del JAR. Por ejemplo, hay una entrada llamada Main-Class que especifica el nombre de la clase Java con la estática main () para archivos JAR ejecutables.

También puede colocar recursos estáticos allí.

Por ejemplo:

META-INF/resources/button.jpg 

y conseguirlos en web3.0-container via

http://localhost/myapp/button.jpg

> Leer más

El /META-INF/MANIFEST.MF tiene un significado especial:

1. Si ejecuta un jar con Java -jar myjar.jar org.myserver.MyMainClass puede mover la definición de la clase principal al jar para poder reducir la llamada a Java -jar myjar.jar.
2. Puede definir Metainformations para paquetes si usa Java.lang.Package.getPackage("org.myserver").getImplementationTitle().
3. Puede hacer referencia a los certificados digitales que desea usar en el modo Applet/Webstart.

Solo para agregar a la información aquí, en el caso de un archivo WAR, el archivo META-INF/MANIFEST.MF proporciona al desarrollador la posibilidad de iniciar una verificación de tiempo de implementación por el contenedor, lo que garantiza que el contenedor pueda encontrar todas las clases de su aplicación depende de. Esto garantiza que, en caso de que haya perdido un JAR, no tenga que esperar hasta que su aplicación funcione en tiempo de ejecución para darse cuenta de que falta.

Agregando a la información aquí, el META-INF es una carpeta especial que la ClassLoader trata de manera diferente a otras carpetas en el contenedor. Los elementos anidados dentro de la carpeta META-INF no se mezclan con los elementos que están fuera de ella.

Piensa en ello como otra raíz. Desde la perspectiva de Enumerator<URL> ClassLoader#getSystemResources(String path) method et al:

Cuando la ruta dada comienza con "META-INF", el método busca recursos que están anidados dentro de las carpetas META-INF de todos los archivos jar en la ruta de clase.

Cuando la ruta dada no comienza con "META-INF", el método busca recursos en todas las demás carpetas (fuera de META-INF) de todos los archivos y directorios en la ruta de clase.

Si conoce otro nombre de carpeta que el método getSystemResources trata especialmente, coméntelo.

He estado pensando en este tema recientemente. Realmente no parece haber ninguna restricción en el uso de META-INF. Hay ciertas restricciones, por supuesto, acerca de la necesidad de poner el manifiesto allí, pero no parece haber ninguna prohibición de poner otras cosas allí.

¿Por qué es este el caso?

El caso cxf puede ser legítimo. Aquí hay otro lugar donde se recomienda este no estándar para evitar un error desagradable en JBoss-ws que evita la validación del lado del servidor contra el esquema de un wsdl.

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

Pero en realidad no parece haber ningún estándar, no hay nada que no debas hacer. Por lo general, estas cosas se definen de manera muy rigurosa, pero por alguna razón, parece que aquí no hay normas. Impar. Parece que META-INF se ha convertido en un punto de encuentro para cualquier configuración necesaria que no pueda manejarse fácilmente de otra manera.

Si está utilizando JPA1, es posible que tenga que colocar un archivo persistence.xml allí que especifique el nombre de una unidad de persistencia que desee utilizar. Una unidad de persistencia proporciona una forma conveniente de especificar un conjunto de archivos de metadatos, clases y archivos jar que contienen todas las clases que se conservarán en una agrupación.

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

// ...

EntityManagerFactory emf =
      Persistence.createEntityManagerFactory(persistenceUnitName);

Vea más aquí: http://www.datanucleus.org/products/datanucleus/jpa/emf.html

META-INF en Maven

En Maven, la carpeta META-INF se entiende debido a Diseño de directorio estándar que por convención de nombre empaqueta sus recursos de proyecto dentro de JARs: cualquier directorio o archivo ubicado dentro de $ {basedir} El directorio/src/main/resources está empaquetado en su JAR con la misma estructura que comienza en la base del JAR. La carpeta $ {basedir}/src/main/resources/META-INF generalmente contiene .properties archivos mientras que en el jar contiene un MANIFEST.MF generado , pom.properties , the pom.xml , entre otros archivos. También los marcos como Spring usan classpath:/META-INF/resources/ para servir los recursos web. Para obtener más información, vea ¿Cómo agrego recursos a mi Proyecto Maven

Todas las respuestas son correctas. Meta-inf tiene muchos propósitos. Además, aquí hay un ejemplo sobre el uso de contenedor Tomcat.

Vaya a Tomcat Doc y verifique el atributo " Implementación estándar> copyXML ".

La descripción está abajo.

Establézcalo en verdadero si desea que un descriptor XML de contexto incrustado dentro de la aplicación (ubicado en /META-INF/context.xml) se copie a la base de XML del Host propietario cuando se implementa la aplicación. En los inicios posteriores, el descriptor XML de contexto copiado se utilizará con preferencia a cualquier descriptor XML de contexto incrustado dentro de la aplicación, incluso si el descriptor incrustado dentro de la aplicación es más reciente. El valor predeterminado de la bandera es falso. Tenga en cuenta que si el atributo deployXML del Host propietario es falso o si el atributo copyXML del Host propietario es verdadero, este atributo no tendrá ningún efecto.

Tiene un archivo MANIFEST.MF dentro de su carpeta META-INF. Puede definir dependencias opcionales o externas a las que debe tener acceso.

Ejemplo:

Considere que ha implementado su aplicación y su contenedor (en tiempo de ejecución) descubrió que su aplicación requiere una versión más nueva de una biblioteca que no está dentro de la carpeta lib, en ese caso, si ha definido la versión más nueva opcional en MANIFEST.MF, entonces su aplicación refiérase a la dependencia desde allí (y no se bloqueará).

Source: Head First Jsp & Servlet