META-INF的目的是什么?

一般来说,你不应该把任何东西放进META-INF中。相反,你应该依靠你用什么来包装你的罐子。这是我认为Ant真正擅长的领域之一:指定JAR文件清单属性。很容易说出这样的话:

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

至少,我觉得这很容易…-)

要点是Meta -IF应该被认为是内部Java。 元 目录。别弄乱了!您希望包含在JAR中的任何文件都应该放在其他子目录或JAR本身的根目录中。

从 the official JAR File Specification (链接转到Java 7版本,但是文本至少自从V1.3以来没有改变):

META-INF目录

Meta -IF目录中的以下文件/目录由Java 2平台识别和解释,以配置应用程序、扩展名、类加载器和服务:

• MANIFEST.MF

用于定义扩展名和包相关数据的清单文件。

• INDEX.LIST

此文件由新的 -i JAR工具的选项,其中包含在应用程序或扩展中定义的包的位置信息。它是jarIndex实现的一部分,类装入器使用它来加速类装入过程。

• x.SF

JAR文件的签名文件。x'代表基本文件名。

• x.DSA

与具有相同基本文件名的签名文件关联的签名块文件。此文件存储相应签名文件的数字签名。

• services/

此目录存储所有服务提供程序配置文件。

我注意到,一些Java库已经开始使用Meta -IF作为一个目录,其中包含配置文件,这些文件应该被打包并包含在类路径中。例如,Spring允许您使用以下命令导入类路径上的XML文件:

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

在这个例子中,我直接引用了 Apache CXF User Guide . 在我工作的一个项目中,我们必须通过Spring允许多个级别的配置,我们遵循这个约定,并将配置文件放在META-INF中。

当我思考这个决定时,我不知道在一个特定的Java包中,而不是在Meta AF中简单地包含配置文件是错误的,但是它似乎是一个新出现的事实标准;或者,或者一个正在出现的反模式:

META-INF文件夹是 MANIFEST.MF 文件。这个文件包含关于jar内容的元数据。例如,有一个名为main类的条目,用可执行JAR文件的static main()指定Java类的名称。

您还可以在其中放置静态资源。

例如:

META-INF/resources/button.jpg 

把它们放在Web3.0容器中,通过

http://localhost/myapp/button.jpg

> Read more

/META-INF/manifest.mf有一个特殊的含义:

1. 如果你用 java -jar myjar.jar org.myserver.MyMainClass 您可以将主类定义移动到jar中,以便将调用收缩为 java -jar myjar.jar .
2. 如果您使用 java.lang.Package.getPackage("org.myserver").getImplementationTitle() .
3. 您可以引用希望在applet/webstart模式下使用的数字证书。

为了在这里添加信息,在使用war文件的情况下,META-INF/manifest.mf文件为开发人员提供了一个工具,可以启动容器的部署时间检查,以确保容器能够找到应用程序所依赖的所有类。这样可以确保在错过JAR的情况下,不必等到应用程序在运行时爆炸时才意识到它丢失了。

在这里添加信息时,META-INF是一个特殊的文件夹, ClassLoader 与JAR中的其他文件夹不同。 嵌套在META-INF文件夹中的元素不与它之外的元素混合。

把它想象成另一个根。从 Enumerator<URL> ClassLoader#getSystemResources(String path) 方法等观点:

当给定的路径以“META-INF”开头时,该方法将搜索嵌套在类路径中所有JAR的META-INF文件夹中的资源。

当给定的路径不是以“META-INF”开头时,该方法将搜索类路径中所有JAR和目录的所有其他文件夹(META-INF之外)中的资源。

如果你知道另一个文件夹名 getSystemResources 方法特别对待,请评论。

我最近一直在考虑这个问题。事实上,对META-INF的使用似乎没有任何限制。当然,有一些关于将清单放在那里的必要性的限制,但是似乎没有任何禁止将其他东西放在那里的限制。

为什么会这样?

CXF案件可能是合法的。这里还有另一个地方,建议使用这个非标准来绕过JBossWS中的一个讨厌的bug,这个bug会阻止针对WSDL模式的服务器端验证。

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

但似乎真的没有任何标准,任何你不应该有的。通常,这些东西都是非常严格的定义,但出于某种原因,这里似乎没有标准。奇怪的。似乎META-INF已经成为任何不容易用其他方法处理的所需配置的一个重要位置。

如果您使用的是JPA1,则可能需要删除 persistence.xml 其中指定您可能要使用的持久性单元的名称的文件。持久性单元提供了一种指定一组元数据文件、类和JAR的方便方法,这些元数据文件、类和JAR包含要在一个分组中持久化的所有类。

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

// ...

EntityManagerFactory emf =
      Persistence.createEntityManagerFactory(persistenceUnitName);

在这里看到更多: http://www.datanucleus.org/products/datanucleus/jpa/emf.html

Maven中的META-INF

在Maven中 美联社 由于 Standard Directory Layout 按名称约定,将项目资源打包到JAR中:放置在 $basedir/src/main/resources 目录被打包到jar中,从jar的底部开始具有完全相同的结构。文件夹 $basedir/src/main/resources/meta-inf 通常包含 性能 JAR中的文件包含生成的 MF宣言 , 庞氏特性 , the XML ,以及其他文件。还有一些框架,比如 Spring 使用 classpath:/META-INF/resources/ 为网络资源服务。有关详细信息,请参阅 How do i add resources to my Maven Project

所有答案都是正确的。META INF有许多用途。此外,这里还有一个关于使用Tomcat容器的示例。

去 Tomcat Doc 并检查 “ 标准实现>copyXML “属性。

说明如下。

如果希望在部署应用程序时将嵌入在应用程序中的上下文XML描述符(位于/meta-inf/context.xml)复制到所属主机的xmlbase,请设置为true。在随后的启动中,复制的上下文XML描述符将优先于嵌入到应用程序中的任何上下文XML描述符,即使嵌入到应用程序中的描述符是最新的。该标志的值默认为false。注意:如果所属主机的deployXML属性为false,或者所属主机的copyXML属性为true,则此属性无效。

您的META-INF文件夹中有manifest.mf文件。你可以 定义可选或外部依赖项 你必须能接触到的。

例子:

假设您已经部署了应用程序,并且您的容器(在运行时)发现您的应用程序需要不在lib文件夹中的库的较新版本,在这种情况下,如果您在 MANIFEST.MF 然后您的应用程序将引用来自那里的依赖关系(并且不会崩溃)。

Source: 头一JSP&servlet