Risposte:
In generale, non dovresti inserire nulla in META-INF. Invece, dovresti fare affidamento su qualsiasi cosa tu usi per impacchettare il tuo JAR. Questa è una delle aree in cui penso che Ant eccelli davvero: specificare gli attributi manifest del file JAR. È molto facile dire qualcosa del tipo:
<jar ...>
<manifest>
<attribute name="Main-Class" value="MyApplication"/>
</manifest>
</jar>Almeno, penso che sia facile ... :-)
Il punto è che META-INF dovrebbe essere considerato una meta directory Java interna . Non scherzare! Tutti i file che si desidera includere con il proprio JAR dovrebbero essere collocati in qualche altra sottodirectory o nella radice del JAR stesso.
Dalla specifica del file JAR ufficiale (il collegamento va alla versione Java 7, ma il testo non è cambiato almeno dalla v1.3):
La directory META-INF
I seguenti file / directory nella directory META-INF sono riconosciuti e interpretati dalla piattaforma Java 2 per configurare applicazioni, estensioni, caricatori di classi e servizi:
MANIFEST.MFIl file manifest utilizzato per definire i dati relativi all'estensione e al pacchetto.
INDEX.LISTQuesto file è generato dalla nuova "
-i" opzione dello strumento jar, che contiene informazioni sulla posizione per i pacchetti definiti in un'applicazione o in un'estensione. Fa parte dell'implementazione JarIndex e viene utilizzato dai programmi di caricamento classi per accelerare il processo di caricamento della classe.
x.SFIl file della firma per il file JAR. 'x' indica il nome del file di base.
x.DSAIl file di blocco della firma associato al file di firma con lo stesso nome del file di base. Questo file memorizza la firma digitale del file della firma corrispondente.
services/Questa directory memorizza tutti i file di configurazione del fornitore di servizi.
Ho notato che alcune librerie Java hanno iniziato a utilizzare META-INF come directory in cui includere i file di configurazione che dovrebbero essere impacchettati e inclusi nel CLASSPATH insieme ai JAR. Ad esempio, Spring consente di importare file XML che si trovano sul percorso di classe utilizzando:
<import resource="classpath:/META-INF/cxf/cxf.xml" />
<import resource="classpath:/META-INF/cxf/cxf-extensions-*.xml" />In questo esempio, sto citando direttamente dalla Guida dell'utente di Apache CXF . Su un progetto a cui ho lavorato in cui dovevamo consentire più livelli di configurazione tramite Spring, abbiamo seguito questa convenzione e messo i nostri file di configurazione in META-INF.
Quando rifletto su questa decisione, non so cosa sarebbe esattamente sbagliato semplicemente includendo i file di configurazione in uno specifico pacchetto Java, piuttosto che in META-INF. Ma sembra essere uno standard di fatto emergente; o quello o un anti-pattern emergente :-)
La cartella META-INF è la home per il file MANIFEST.MF . Questo file contiene metadati sul contenuto del JAR. Ad esempio, esiste una voce chiamata Main-Class che specifica il nome della classe Java con il main statico () per i file JAR eseguibili.
Puoi anche inserire risorse statiche lì.
Per esempio:
META-INF/resources/button.jpg e ottenerli nel contenitore web3.0 tramite
http://localhost/myapp/button.jpgIl /META-INF/MANIFEST.MF ha un significato speciale:
java -jar myjar.jar org.myserver.MyMainClassè possibile spostare la definizione della classe principale nel jar in modo da ridurre la chiamata java -jar myjar.jar.java.lang.Package.getPackage("org.myserver").getImplementationTitle().In Maven la cartella META-INF è compresa a causa del layout di directory standard , che per convenzione convenziona le risorse del progetto all'interno di JAR: tutte le directory o i file inseriti nella directory $ {basedir} / src / main / resources sono impacchettati nel tuo JAR con la stessa identica struttura a partire dalla base del JAR. La cartella $ {basedir} / src / main / resources / META-INF di solito contiene file .properties mentre nel vaso contiene un MANIFEST.MF generato , pom.properties , il pom.xml , tra gli altri file. Anche i framework come Spring usano classpath:/META-INF/resources/per servire le risorse web. Per ulteriori informazioni, vedereCome faccio ad aggiungere risorse al mio progetto Maven .
Solo per aggiungere alle informazioni qui, nel caso di un file WAR, il file META-INF / MANIFEST.MF fornisce allo sviluppatore una funzione per avviare un controllo del tempo di distribuzione dal contenitore che assicura che il contenitore possa trovare tutte le classi dell'applicazione dipende da. Ciò garantisce che nel caso in cui si sia perso un JAR, non è necessario attendere fino a quando l'applicazione non viene scaricata durante l'esecuzione per rendersi conto che manca.
Ho pensato a questo problema di recente. Non sembra esserci alcuna restrizione sull'uso di META-INF. Ci sono alcune restrizioni, ovviamente, sulla necessità di mettere lì il manifest, ma non sembra esserci alcun divieto di mettere lì altre cose.
Perché è così?
Il caso cxf può essere legittimo. Ecco un altro posto in cui questo non standard è raccomandato per aggirare un brutto bug in JBoss-ws che impedisce la validazione sul lato server contro lo schema di un wsdl.
http://community.jboss.org/message/570377#570377
Ma in realtà non sembrano esserci standard, né tu-non-non. Di solito queste cose sono definite in modo molto rigoroso, ma per qualche ragione, sembra che non ci siano standard qui. Dispari. Sembra che META-INF sia diventato un luogo ideale per qualsiasi configurazione necessaria che non può essere facilmente gestita in altro modo.
Aggiungendo alle informazioni qui, META-INF è una cartella speciale che ClassLoadertratta diversamente dalle altre cartelle nel vaso. Gli elementi nidificati all'interno della cartella META-INF non vengono mescolati con gli elementi esterni.
Pensalo come un'altra radice. Dalla Enumerator<URL> ClassLoader#getSystemResources(String path)prospettiva method et al:
Quando il percorso specificato inizia con "META-INF", il metodo cerca le risorse che sono nidificate all'interno delle cartelle META-INF di tutti i barattoli nel percorso di classe.
Quando il percorso specificato non inizia con "META-INF", il metodo cerca le risorse in tutte le altre cartelle (al di fuori del META-INF) di tutti i barattoli e le directory nel percorso della classe.
Se conosci un altro nome di cartella che il getSystemResourcesmetodo tratta in modo speciale, ti preghiamo di commentarlo.
Se stai usando JPA1, potresti dover inserire un persistence.xmlfile che specifica il nome di un'unità di persistenza che potresti voler usare. Un'unità di persistenza fornisce un modo conveniente per specificare un insieme di file di metadati, classi e barattoli che contengono tutte le classi da conservare in un raggruppamento.
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;
// ...
EntityManagerFactory emf =
Persistence.createEntityManagerFactory(persistenceUnitName);Scopri di più qui: http://www.datanucleus.org/products/datanucleus/jpa/emf.html
Tutte le risposte sono corrette Meta-inf ha molti scopi. Inoltre, ecco un esempio sull'uso del contenitore Tomcat.
Vai a Tomcat Doc e seleziona l' attributo " Implementazione standard> copyXML ".
La descrizione è sotto.
Impostare su true se si desidera che un descrittore XML di contesto incorporato nell'applicazione (disponibile in /META-INF/context.xml) venga copiato nella base xml dell'host proprietaria quando l'applicazione viene distribuita. Agli avvii successivi, il descrittore XML di contesto copiato verrà utilizzato preferibilmente a qualsiasi descrittore XML di contesto incorporato nell'applicazione anche se il descrittore incorporato nell'applicazione è più recente. Il valore della bandiera viene impostato automaticamente su falso. Nota se l'attributo deployXML dell'host proprietario è falso o se l'attributo copyXML dell'host proprietario è vero, questo attributo non avrà alcun effetto.
Hai file MANIFEST.MF nella cartella META-INF. È possibile definire dipendenze opzionali o esterne a cui è necessario avere accesso.
Esempio:
Considera di aver distribuito la tua app e il tuo contenitore (in fase di esecuzione) ha scoperto che la tua app richiede una versione più recente di una libreria che non si trova all'interno della cartella lib, in tal caso se hai definito la versione più recente opzionale, la MANIFEST.MFtua app farà riferimento alla dipendenza da lì (e non andrà in crash).
Source: Head First Jsp e Servlet