Maven中的META-INF

在Maven中，META-INF文件夹被理解是因为标准目录布局，根据名称约定将您的项目资源打包到JAR中:放置在${basedir}/src/main/resources目录中的任何目录或文件都以完全相同的结构打包到JAR中，从JAR的底部开始。

文件夹${basedir}/src/main/resources/META-INF通常包含。properties文件，而在jar中包含一个生成的MANIFEST。MF,砰的一声。属性，pom.xml，以及其他文件。同样，像Spring这样的框架使用classpath:/META-INF/resources/来提供web资源。

有关更多信息，请参阅如何向Maven项目添加资源。

你有舱单。MF文件在你的META-INF文件夹。您可以定义必须访问的可选或外部依赖项。

例子:

假设你已经部署了你的应用程序，你的容器(在运行时)发现你的应用程序需要一个不在lib文件夹内的库的新版本，在这种情况下，如果你在MANIFEST中定义了可选的新版本。MF，那么你的应用程序将从那里引用依赖(不会崩溃)。

来源:Head First Jsp & Servlet

我注意到一些Java库已经开始使用META-INF作为目录，其中包含应该打包并与jar一起包含在CLASSPATH中的配置文件。例如，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是一个特殊的文件夹，ClassLoader将其与jar中的其他文件夹区别对待。 嵌套在META-INF文件夹内的元素不会与它外部的元素混合。

把它想象成另一个根。从Enumerator<URL> ClassLoader#getSystemResources(字符串路径)方法等透视图:

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

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

如果您知道getSystemResources方法特别处理的另一个文件夹名称，请对其进行评论。

我最近一直在思考这个问题。对于META-INF的使用似乎真的没有任何限制。当然，有一些限制，关于把舱单放在那里的必要性，但似乎没有任何禁止把其他东西放在那里。

为什么会这样呢?

cxf案例可能是合法的。这里是建议使用非标准的另一个地方，它可以绕过JBoss-ws中防止针对wsdl模式进行服务器端验证的严重错误。

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

但似乎真的没有什么标准，没有什么千言万语。通常这些事情都有非常严格的定义，但出于某种原因，这里似乎没有标准。奇数。META-INF似乎已经成为了一个无所不包的地方，任何所需的配置都无法通过其他方式轻松处理。

你也可以在那里放置静态资源。

在示例:

META-INF/resources/button.jpg 

并通过web3.0容器获取它们

http://localhost/myapp/button.jpg

>阅读更多

/ meta - inf / MANIFEST。MF有特殊的含义:

如果你使用java -jar myjar.jar org.myserver.MyMainClass运行一个jar，你可以将主类定义移动到jar中，这样你就可以将调用缩小到java -jar myjar.jar。 如果你使用java.lang.Package.getPackage("org.myserver"). getimplementationtitle()，你可以为包定义元结构。 您可以在Applet/Webstart模式中引用您喜欢的数字证书。