META-INFの目的は何ですか？

Javaでは、いくつかのメタファイルを含むMETA-INFフォルダーがよくあります。このフォルダの目的は何ですか、そこに何を置くことができますか？

一般的に、META-INFには何も入れないでください。代わりに、JARのパッケージ化に使用するものに依存する必要があります。これは、Antが本当に優れていると思う領域の1つです。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を、JARとともにパッケージ化してCLASSPATHに含める必要がある構成ファイルを入れるディレクトリーとして使用し始めていることに気付きました。たとえば、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に配置しました。

この決定を振り返ると、META-INFではなく特定のJavaパッケージに構成ファイルを単に含めるだけで何が問題になるのか正確にはわかりません。しかし、それは新しい事実上の標準のようです。それ、または新たなアンチパターン:-)

META-INFフォルダーは、MANIFEST.MFファイルのホームです。このファイルには、JARの内容に関するメタデータが含まれています。たとえば、実行可能JARファイルの静的main（）でJavaクラスの名前を指定するMain-Classというエントリがあります。

そこに静的リソースを配置することもできます。

例では：

META-INF/resources/button.jpg 

そしてそれらを経由してweb3.0-containerに取得します

http://localhost/myapp/button.jpg

>続きを読む

/META-INF/MANIFEST.MFには特別な意味があります。

1. を使用してjarを実行する場合はjava -jar myjar.jar org.myserver.MyMainClass、メインクラス定義をjarに移動して、呼び出しをに縮小できますjava -jar myjar.jar。
2. を使用すると、パッケージにメタ情報を定義できますjava.lang.Package.getPackage("org.myserver").getImplementationTitle()。
3. アプレット/ Webstartモードで使用するデジタル証明書を参照できます。

MavenのMETA-INF

Mavenでは、META-INFフォルダーは、標準のディレクトリレイアウトにより、JAR内のプロジェクトリソースを規則でパッケージ化することで理解されます。$ {basedir} / src / main / resourcesディレクトリ内に配置されたディレクトリまたはファイルは、JARにパッケージ化されます。 JARのベースから始まるまったく同じ構造です。フォルダー$ {basedir} / src / main / resources / META-INFには通常、.propertiesファイルが含まれていますが、jarには、生成されたMANIFEST.MF、pom.properties、 pom.xmlなどのファイルが含まれています。また、Springのようなフレームワークは、classpath:/META-INF/resources/Webリソースを提供するために使用します。詳細については、Mavenプロジェクトにリソースを追加するにはどうすればよいですか。

ここに情報を追加するだけで、WARファイルの場合、META-INF / MANIFEST.MFファイルは、コンテナーがアプリケーションによるすべてのクラスを確実に検出できるようにするコンテナーによるデプロイ時間チェックを開始する機能を開発者に提供します依存します。これにより、JARを見逃した場合でも、アプリケーションが実行時にブローするまで待って、JARが欠落していることに気付く必要がなくなります。

最近この問題について考えています。META-INFの使用に関する制限はないようです。もちろん、マニフェストをそこに配置する必要性については特定の制限がありますが、他のものをそこに配置することに対する禁止事項はないようです。

これはなぜですか？

cxfケースは正当な場合があります。wsdlのスキーマに対するサーバー側の検証を妨げるJBoss-wsの厄介なバグを回避するためにこの非標準が推奨される別の場所を次に示します。

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

しかし、実際にはどのような基準もないように思われます。通常、これらは非常に厳密に定義されていますが、何らかの理由で、ここには標準がないようです。奇数。META-INFは、他の方法では簡単に処理できない必要な構成のすべての場所になったようです。

ここでの情報に加えて、META-INFはClassLoaderjar内の他のフォルダーとは異なる扱いをする特別なフォルダーです。META-INFフォルダー内にネストされたエレメントは、その外部のエレメントと混合されません。

別のルートのように考えてください。Enumerator<URL> ClassLoader#getSystemResources(String path)メソッドらの視点：

指定されたパスが「META-INF」で始まる場合、メソッドはクラスパス内のすべてのjarのMETA-INFフォルダー内にネストされているリソースを検索します。

指定されたパスが「META-INF」で始まらない場合、メソッドは、クラスパス内のすべてのjarおよびディレクトリのその他のすべてのフォルダー（META-INF以外）でリソースを検索します。

getSystemResourcesメソッドが特別に扱う別のフォルダー名について知っている場合は、コメントしてください。

JPA1を使用している場合は、使用する可能性persistence.xmlのある永続性ユニットの名前を指定するファイルをそこにドロップする必要がある場合があります。persistence-unitは、メタデータファイル、クラス、およびグループ化で永続化されるすべてのクラスを含むjarのセットを指定する便利な方法を提供します。

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

// ...

EntityManagerFactory emf =
      Persistence.createEntityManagerFactory(persistenceUnitName);

詳細はこちら：http : //www.datanucleus.org/products/datanucleus/jpa/emf.html

すべての答えは正しいです。meta-infには多くの目的があります。また、tomcatコンテナの使用例を次に示します。

Tomcat Docに移動し 、「Standard Implementation> copyXML」属性を確認します。

説明は以下の通りです。

アプリケーションのデプロイ時に、アプリケーション内に埋め込まれた（/META-INF/context.xmlにある）コンテキストXML記述子を所有ホストのxmlBaseにコピーする場合は、trueに設定します。以降の起動では、アプリケーション内に埋め込まれた記述子がより新しい場合でも、コピーされたコンテキストXML記述子が、アプリケーション内に埋め込まれたコンテキストXML記述子よりも優先して使用されます。フラグの値のデフォルトはfalseです。所有ホストのdeployXML属性がfalseである場合、または所有ホストのcopyXML属性がtrueである場合、この属性は効果がないことに注意してください。

META-INFフォルダー内にMANIFEST.MFファイルがあります。アクセスする必要があるオプションの依存関係または外部の依存関係を定義できます。

例：

アプリをデプロイし、コンテナーが（実行時に）libフォルダー内にない新しいバージョンのライブラリーを必要とすることがわかったとします。その場合、オプションの新しいバージョンを定義するとMANIFEST.MF、アプリが参照します。そこから依存関係に（そしてクラッシュしません）。

Source: 最初のJSPとサーブレット