Yanıtlar:
Genel olarak konuşursak, META-INF'e hiçbir şey koymamalısınız. Bunun yerine, JAR'inizi paketlemek için kullandığınız her şeye güvenmelisiniz. Bu Ant gerçekten excels düşünüyorum alanlarından biridir: JAR dosyası manifest öznitelikleri belirtme. Şöyle bir şey söylemek çok kolay:
<jar ...>
<manifest>
<attribute name="Main-Class" value="MyApplication"/>
</manifest>
</jar>En azından bence bu kolay ... :-)
Mesele şu ki META-INF bir dahili Java meta dizini olarak düşünülmelidir . Onunla uğraşma! JAR'nıza dahil etmek istediğiniz dosyalar başka bir alt dizine veya JAR'ın kök dizinine yerleştirilmelidir.
Gönderen resmi JAR Dosya Şartname (link Java 7 sürümüne giden, ancak metin en az v1.3 az beri değişmemiş):
META-INF dizini
META-INF dizinindeki aşağıdaki dosyalar / dizinler, uygulamaları, uzantıları, sınıf yükleyicileri ve hizmetleri yapılandırmak için Java 2 Platformu tarafından tanınır ve yorumlanır:
MANIFEST.MFUzantı ve paketle ilgili verileri tanımlamak için kullanılan manifest dosyası.
INDEX.LISTBu dosya,
-ibir uygulamada veya uzantıda tanımlanan paketler için konum bilgilerini içeren kavanoz aracının yeni " " seçeneği tarafından oluşturulur . JarIndex uygulamasının bir parçasıdır ve sınıf yükleyicileri tarafından sınıf yükleme işlemlerini hızlandırmak için kullanılır.
x.SFJAR dosyasının imza dosyası. 'x' temel dosya adını gösterir.
x.DSAAynı temel dosya adına sahip imza dosyasıyla ilişkili imza bloğu dosyası. Bu dosya, karşılık gelen imza dosyasının dijital imzasını saklar.
services/Bu dizin tüm servis sağlayıcı yapılandırma dosyalarını saklar.
Bazı Java kütüphanelerinin, JAR'larla birlikte paketlenip CLASSPATH'a dahil edilmesi gereken yapılandırma dosyalarını içerecek bir dizin olarak META-INF'yi kullanmaya başladığını fark ettim. Örneğin, Spring sınıf yolundaki XML Dosyalarını aşağıdakileri kullanarak içe aktarmanıza olanak tanır:
<import resource="classpath:/META-INF/cxf/cxf.xml" />
<import resource="classpath:/META-INF/cxf/cxf-extensions-*.xml" />Bu örnekte, doğrudan Apache CXF Kullanıcı Kılavuzu'ndan alıntı yapıyorum . Spring üzerinden birden fazla konfigürasyona izin vermek zorunda kaldığımız bir projede, bu sözleşmeyi izledik ve konfigürasyon dosyalarımızı META-INF'e koyduk.
Bu kararı düşündüğümde, yapılandırma dosyalarını META-INF yerine belirli bir Java paketine dahil etmenin tam olarak neyin yanlış olacağını bilmiyorum. Fakat ortaya çıkan fiili bir standart gibi görünüyor; bu ya da ortaya çıkan bir anti-desen :-)
META-INF klasörü, MANIFEST.MF dosyasının ana sayfasıdır . Bu dosya JAR içeriği hakkında meta veriler içermektedir. Örneğin, yürütülebilir sınıf JAR dosyaları için statik main () ile Java sınıfının adını belirten Main-Class adlı bir girdi vardır.
Oraya statik kaynaklar da yerleştirebilirsiniz.
Örnek olarak:
META-INF/resources/button.jpg ve web3.0 kapsayıcısında
http://localhost/myapp/button.jpg/META-INF/MANIFEST.MF'nin özel bir anlamı vardır:
java -jar myjar.jar org.myserver.MyMainClass, ana sınıf tanımını kavanozun içine taşıyabilirsiniz, böylece aramayı daraltabilirsiniz java -jar myjar.jar.java.lang.Package.getPackage("org.myserver").getImplementationTitle().Maven'de META-INF klasörü, standart kural düzeni nedeniyle anlaşılır ve ad kuralı proje kaynaklarınızı JAR'lar içinde paketler: $ {basedir} / src / main / resources dizinine yerleştirilmiş tüm dizinler veya dosyalar JAR'ınıza paketlenir tam olarak aynı yapı JAR tabanından başlayarak. Klasör $ {basedir} / src / main / resources / META-INF genellikle içerdiği .properties kavanoza bir oluşturulan içeriyor ise dosyaları MANIFEST.MF , pom.properties , pom.xml diğer dosyalar arasında. Ayrıca Bahar kullanımı gibi çerçevelerclasspath:/META-INF/resources/ web kaynakları hizmet etmek. Daha fazla bilgi için, bkzMaven Projeme nasıl kaynak eklerim .
Sadece buradaki bilgilere eklemek için, bir WAR dosyası durumunda, META-INF / MANIFEST.MF dosyası, geliştiriciye, kap tarafından uygulamanızın tüm sınıfları bulabilmesini sağlayan kapsayıcı tarafından bir dağıtım zamanı denetimi başlatma olanağı sağlar. bağlıdır. Bu, bir JAR'ı kaçırmanız durumunda, uygulamanızın eksik olduğunu fark etmek için çalışma zamanında patlamasını beklemek zorunda kalmamanızı sağlar.
Son zamanlarda bu konuyu düşünüyorum. META-INF kullanımında gerçekten herhangi bir kısıtlama yok gibi görünüyor. Tabii ki, tezahürü oraya koymanın gerekliliği ile ilgili bazı darlıklar var, ancak oraya başka şeyler koymakla ilgili herhangi bir yasak yok gibi görünüyor.
Neden böyle?
Cxf durumu yasal olabilir. Bu standart dışı JBoss-ws bir wsdl şemasına karşı sunucu tarafı doğrulamasını önleyen kötü bir hata almak için tavsiye başka bir yer.
http://community.jboss.org/message/570377#570377
Ama gerçekten herhangi bir standart var gibi görünmüyor. Genellikle bunlar çok titizlikle tanımlanır, ancak bir nedenden dolayı burada standart yok gibi görünüyor. Garip. Öyle görünüyor ki META-INF, başka herhangi bir şekilde kolayca ele alınamayan herhangi bir yapılandırma için bir yer haline gelmiştir.
Buradaki bilgilere ek olarak META-INF, ClassLoaderkavanozdaki diğer klasörlerden farklı davranan özel bir klasördür . META-INF klasörünün içine yerleştirilen öğeler, dışındaki öğelerle karıştırılmaz.
Başka bir kök gibi düşünün. Kaynaktan Enumerator<URL> ClassLoader#getSystemResources(String path)yöntem ve ark açısından:
Belirtilen yol "META-INF" ile başladığında, yöntem sınıf yolundaki tüm kavanozların META-INF klasörlerinin içine yerleştirilmiş kaynakları arar.
Belirtilen yol "META-INF" ile başlamazsa, yöntem sınıf yolundaki tüm kavanozların ve dizinlerin diğer tüm klasörlerindeki (META-INF dışında) kaynakları arar.
getSystemResourcesYöntemin özel olarak ele aldığı başka bir klasör adı biliyorsanız , lütfen bu konu hakkında yorum yapın.
JPA1 kullanıyorsanız, kullanmak isteyebileceğiniz persistence.xmlbir kalıcılık biriminin adını belirten bir dosya bırakmanız gerekebilir. Kalıcılık birimi, bir grup veri içinde kalıcı olacak tüm sınıfları içeren bir dizi meta veri dosyası, sınıf ve kavanoz belirtmek için uygun bir yol sağlar.
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;
// ...
EntityManagerFactory emf =
Persistence.createEntityManagerFactory(persistenceUnitName);Buradan daha fazlasını görün: http://www.datanucleus.org/products/datanucleus/jpa/emf.html
Tüm cevaplar doğru. Meta-inf'nin birçok amacı vardır. Buna ek olarak, burada tomcat kabı kullanımına ilişkin bir örnek verilmiştir.
Tomcat Doc'a gidin ve " Standart Uygulama> copyXML'yi kontrol edin " özelliğini .
Açıklama aşağıdadır.
Uygulama içine gömülü bir bağlam XML tanımlayıcısının (/META-INF/context.xml dosyasında bulunur), uygulama dağıtıldığında sahip olan Ana Bilgisayarın xmlBase öğesine kopyalanmasını istiyorsanız true olarak ayarlayın. Sonraki başlangıçlarda, kopyalanan bağlam XML tanımlayıcısı, uygulamanın içine gömülü tanımlayıcı daha yeni olsa bile, uygulamanın içine yerleştirilmiş herhangi bir bağlam XML tanımlayıcısının yerine kullanılacaktır. Bayrağın değeri varsayılan olarak false olur. Sahip olan Ana Bilgisayarın deployXML özniteliği yanlışsa veya sahip Ana Bilgisayarın copyXML özniteliği doğru ise, bu özniteliğin bir etkisi olmayacağını unutmayın.
META-INF klasörünüzün içinde MANIFEST.MF dosyanız var. Şunları yapabilirsiniz isteğe bağlı veya dış bağımlılıkları tanımlamak size erişimi olmalıdır.
Misal:
Uygulamanızı dağıttığınızı ve kapsayıcınızın (çalışma zamanında) uygulamanızın lib klasörünün içinde olmayan yeni bir kitaplık sürümü gerektirdiğini, bu durumda isteğe bağlı yeni sürümü tanımladıysanız, MANIFEST.MFuygulamanızın oradan bağımlılığa (ve çökmeyecek).
Source: İlk Baş Jsp ve Servlet