En Java, vous voyez souvent un dossier META-INF contenant certains fichiers méta. À quoi sert ce dossier et que puis-je y mettre ?
Les TLD doivent également figurer sous META-INF.
En Java, vous voyez souvent un dossier META-INF contenant certains fichiers méta. À quoi sert ce dossier et que puis-je y mettre ?
De la spécification officielle des fichiers JAR (le lien renvoie à la version Java 7, mais le texte n'a pas changé depuis au moins la v1.3) :
Le répertoire META-INF
Les fichiers/répertoires suivants du répertoire META-INF sont reconnus et interprétés par la plate-forme Java 2 pour configurer les applications, les extensions, les chargeurs de classes et les services :
MANIFEST.MF
Le fichier manifeste qui est utilisé pour définir les données relatives aux extensions et aux paquets.
INDEX.LIST
Ce fichier est généré par le nouveau "
-i
"Cette option de l'outil jar contient des informations sur l'emplacement des paquets définis dans une application ou une extension. Elle fait partie de l'implémentation de JarIndex et est utilisée par les chargeurs de classes pour accélérer leur processus de chargement des classes.
x.SF
Le fichier de signature pour le fichier JAR. x' représente le nom du fichier de base.
x.DSA
Le fichier de bloc de signature associé au fichier de signature ayant le même nom de fichier de base. Ce fichier stocke la signature numérique du fichier de signature correspondant.
services/
Ce répertoire stocke tous les fichiers de configuration du fournisseur de services.
D'une manière générale, vous ne devez rien mettre vous-même dans META-INF. Vous devriez plutôt vous fier à ce que vous utilisez pour empaqueter votre JAR. C'est l'un des domaines où je pense que Ant excelle vraiment : spécifier les attributs du manifeste du fichier JAR. Il est très facile de dire quelque chose comme :
<jar ...>
<manifest>
<attribute name="Main-Class" value="MyApplication"/>
</manifest>
</jar>
Du moins, je pense que c'est facile... :-)
Le fait est que META-INF doit être considéré comme un élément interne de Java. méta annuaire. N'y touchez pas ! Tous les fichiers que vous souhaitez inclure dans votre JAR doivent être placés dans un autre sous-répertoire ou à la racine du JAR lui-même.
Qu'en est-il des services ? Les descripteurs de bibliothèque de balises ? Placer quelque chose dans la racine d'un JAR est une mauvaise idée. En l'absence d'une convention claire, les ressources situées dans la racine sont trop susceptibles d'entrer en collision.
Si vous utilisez JPA, vous devez placer un fichier persistence.xml dans ce dossier, ce qui ne se fait pas automatiquement.
Ce serait une bonne réponse, sauf que dans une application Spring MVC simple, META-INF est le seul répertoire où les fichiers de configuration peuvent être référencés à la fois par les tests unitaires et les contrôleurs. Si un autre répertoire fonctionnait, ce serait génial, mais ce n'est pas le cas (du moins pas de manière directe). Pour moi, construire un fichier Jar juste pour tester un fichier war est comme construire une voiture pour pouvoir marcher jusqu'à la cuisine. Du moins pour moi. Mais j'ai passé un certain temps à faire du Ruby, et ils m'ont peut-être ruiné en ce qui concerne les fichiers de configuration (bien que j'échange un peu d'enfer XML pour savoir quels sont les types de mes paramètres). :)
J'ai remarqué que certaines bibliothèques Java ont commencé à utiliser META-INF comme répertoire dans lequel inclure des fichiers de configuration qui devraient être empaquetés et inclus dans le CLASSPATH avec les JARs. Par exemple, Spring vous permet d'importer des fichiers XML qui sont sur le classpath en utilisant :
<import resource="classpath:/META-INF/cxf/cxf.xml" />
<import resource="classpath:/META-INF/cxf/cxf-extensions-*.xml" />
Dans cet exemple, je cite directement le texte de l'accord de coopération entre l'Union européenne et la France. Guide de l'utilisateur d'Apache CXF . Dans le cadre d'un projet sur lequel j'ai travaillé et dans lequel nous devions permettre plusieurs niveaux de configuration via Spring, nous avons suivi cette convention et placé nos fichiers de configuration dans META-INF.
Quand je réfléchis à cette décision, je ne sais pas exactement ce qu'il y aurait de mal à inclure simplement les fichiers de configuration dans un paquetage Java spécifique, plutôt que dans META-INF. Mais il semble qu'il s'agisse d'une norme de facto émergente ; soit cela, soit un anti-modèle émergent :-)
Configuraton n'a pas sa place dans une bibliothèque. Je pense que vous avez trouvé le mot "anti-modèle émergent". Il est vraiment très facile de localiser les fichiers de configuration relatifs à une bibliothèque ; ils n'ont pas besoin d'être physiquement dans le même JAR pour être trouvés.
Je ne suis pas d'accord avec l'affirmation selon laquelle la configuration n'a pas sa place dans une bibliothèque. Je pense que la configuration, en particulier lorsqu'il s'agit de valeurs par défaut, est très bien intégrée dans une bibliothèque. En fait, je suis content que de plus en plus de frameworks choisissent de travailler de cette manière plutôt que de vous forcer à inclure toutes sortes de fichiers de configuration externes comme c'était le cas il n'y a pas si longtemps.
J'ai vu beaucoup de fichiers de type LICENSE.TXT apparaître dans META_INF également, ce que je trouve ennuyeux.
Le dossier META-INF est l'endroit où se trouvent les éléments suivants MANIFEST.MF fichier. Ce fichier contient des métadonnées sur le contenu du JAR. Par exemple, il y a une entrée appelée Main-Class qui spécifie le nom de la classe Java avec la fonction statique main() pour les fichiers JAR exécutables.
Pour compléter l'information, dans le cas d'un fichier WAR, le fichier META-INF/MANIFEST.MF permet au développeur de lancer une vérification au moment du déploiement par le conteneur qui s'assure que le conteneur peut trouver toutes les classes dont dépend votre application. Ainsi, si vous avez oublié un JAR, vous n'avez pas à attendre que votre application explose au moment de l'exécution pour vous rendre compte de son absence.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
18 votes
Travailler avec des fichiers de manifeste : Les bases