Jar MANIFEST. MF Rollup

：

manifest-version:1.0
Created-by:apache Ant 1.5.1
Extension-name:struts Framework
Specification-title:struts Framework
Specification-vendor:apache Software Foundation
specification-version:1.1
Implementation-title:struts Framework
Implementation-vendor:apache Software Foundation
Implementation-vendor-id:org.apache
implementation-version:1.1
Class-path:commons-beanutils.jar Commons-collections.jar Commons-dig
Ester.jar Commons-logging.jar Commons-validator.jar Jakarta-oro.jar s
Truts-legacy.jar

If we classify the configuration information in manifest, we can summarize the following categories:

I. GENERAL properties

1. Manifest-version
Used to define the version of the Manifest file, for example: manifest-version:1.0
2. created-by
Declares the creator of the file, typically this property is generated by the JAR command-line tool, for example: Created-by:apache Ant 1.5.1
3. Signature-version
Defining a signature version of a jar file
4. Class-path
The application or class loader uses this value to build an internal class search path

Two. Application-related properties

1. Main-class
Defines the entry class for the jar file, which must be an executable class that, once defined, can run the jar file through Java-jar X.jar.

Three. applets (applet) related properties

1. Extendsion-list
This property specifies the list of extended information required by the applet, and each name in the list corresponds to the following attribute
2. <extension>-extension-name
3. <extension>-specification-version
4. <extension>-implementation-version
5. <extension>-implementation-vendor-id
5. <extension>-implementation-url

Four. Extended Identity Properties

1. Extension-name
This property defines the identity of the jar file, such as the Extension-name:struts Framework

Five. Package Extension Properties

1. Implementation-title defines the title of the extension implementation
2. Implementation-version defines the version of the extension implementation
3. Implementation-vendor defines the organization that extends the implementation
4. Implementation-vendor-id defines the identity of the organization to which the extension is implemented
5. Implementation-url: Define the Extension package (URL)
6. Specification-title defines the title of the extension specification
7. Specification-version defines the version of the extension specification
8. Specification-vendor declares the organization that maintains the specification.
9. Sealed defines if the jar file is sealed and the value can be true or false (I don't quite understand that)

Six. Signature-related properties

Signature Properties We can refer to a section of the Mail.jar provided by JavaMail

Name:javax/mail/address.class
Digest-algorithms:sha MD5
sha-digest:ajr7rqnn//cdygouxbd06msvfi4=
md5-digest:zntiq2aqatsniowxi1pqpw==

This section defines the class name of the class signature, the algorithm name of the calculation digest, and the corresponding digest content (encoded using the base method)

Seven. Custom attributes

In addition to some of the properties mentioned earlier, you can also add your own properties and the values of the responses in MANIFEST.MF, such as the J2ME program jar package may contain the following information

microedition-configuration:cldc-1.0
Midlet-name:j2me_mobber MIDlet Suite
Midlet-info-url:http://www.javayou.com
Midlet-icon:/icon.png
Midlet-vendor:midlet Suite Vendor
MIDlet-1: Mobber,/icon.png,mobber
midlet-version:1.0.0
microedition-profile:midp-1.0
Midlet-description:communicator

The point is, how do we read this information? In fact, the JDK provides us with the API for handling this information, see the Java.util.jar package, we can pass the path of a jar file to Jarfile, Then call Jarfile's Getmanifest method to get manifest information.

----------------------------------------------------------------------------------------------

Today in the production of executable jar file, I generated the jar file is Hello.jar, in the MANIFEST.MF Add Main-class property, when writing the main class, encountered a path representation.
Tried the following way, one and two are correct:
Way One:
Main-class:com. Test
Or way two:
Main-class:com/test

In the form of one or two means, after generating the Hello.jar package, the Java-jar Hello.jar can be performed successfully.


And the following way is wrong, way three:
Main-class:com\test

By the way three write, with Java-jar Hello.jar, will report error: Cannot find or can not load the main class Com\test

----------------------------------------------------------------------------------------------

1. Enter "Jar-help" on the command line, and you can see the detailed usage of the jar in K.

2. Example:

1) Archive Two class documents into a JAR file: JAR-CVF xx.jar a.class B.class

2) Use the manifest file MANIFEST.MF to archive all files in the Dir directory into a jar: JAR-CVFM xx.jar manifest.mf dir/*

The format of the manifest file is simple, and each line is a "name-value" corresponding to:

The property name begins with ":" followed by the property value, with a maximum of 72 characters per line, and if necessary, you can continue the line on the next line, the continuation line begins with a space, and the line beginning with a space is treated as a continuation of the previous line.
Use the M option to pass in the manifest file of the specified file name, for example
Jar CVFM Myapplication.jar MYAPPLICATION.MF [-c]classdir

Detailed usage of MANIFEST.MF (RPM)

Now let's take a look at the role of the manifest file, and if we now have a Java application packaged in Myapplication.jar, the main class is Com.example.myapp.MyAppMain, Then we can use the following command to run
Java-classpath Myapplication.jar Com.example.myapp.MyAppMain
This is obviously too troublesome, now let's create our own manifest file, as follows:
manifest-version:1.0
CREATED-BY:JDJ Example
Main-class:com.example.myapp.myappmain
This way we can use the following command to run the program: (obviously more simple, and will not cause unnecessary spelling mistakes)
Java-jar Myapplication.jar

Managing dependency resources for Jars
Few Java applications will have just one jar file and typically require other class libraries. For example, my application uses Sun's Javamail classes, I need to include Activation.jar and Mail.jar in Classpath, so when we run the program, we'll add some more than the example above:
Java- Classpath Mail.jar:activation.jar-jar Myapplication.jar
in different operating systems, the delimiter between jar packages is not the same, in Unix with ":", in the window using ";", It's not convenient.
Again, we rewrite our Manifest file as follows
manifest-version:1.0
Created-by:jdj example
Main-class: Com.example.myapp.MyAppMain
Class-path:mail.jar Activation.jar
(added Class-path:mail.jar Activation.jar, two jar packages separated by a space)
so we can still execute the program with the same command as in the example above:
Java-jar Myapplication.jar
The Class-path attribute contains a space-delimited jar file in which to use escape characters for specific characters, such as spaces, to be represented as "", and to separate directories () in the representation of a path, regardless of the operating system, (even in window), And here is the relative path (relative to its own jar file):  
manifest-version:1.0
Created-by:jdj example
Main-class: Com.example.myapp.MyAppMain
Class-path:ext/mail.jar Ext/activation.jar

Multiple main Classes (multi-master Class)
There is also a multiple main classes case where you might have multiple main classes if your application might have command-line versions and GUI versions, or if some different applications share many of the same code. We recommend that you take this strategy: the shared class into the Lib package, and then the different applications into different packages, the main class is marked as follows:
Manifest for Myapplicationlib.jar:
manifest-version:1.0
CREATED-BY:JDJ Example
Class-path:mail.jar Activation.jar

Manifest for Myappconsole.jar:
manifest-version:1.0
CREATED-BY:JDJ Example
Class-path:myapplicationlib.jar
Main-class:com.example.myapp.myappmain

Manifest for Myappadmin.jar:
manifest-version:1.0
CREATED-BY:JDJ Example
Class-path:myapplicationlib.jar
Main-class:com.example.myapp.myadmintool
In the Myappconsole.jar and Myappadmin.jar manifest files, separate the Main Class
Package Versioning
After publishing, if the user wants to know, which code is who? What is the current version? What version of the class library do you use? There are many workarounds, and manifest provides a better way to describe each package in the manifest file.

Java adheres to the principle of separating the implementation description from the description, and the package description defines what the package is, and the implementation description defines who provided the description of the implementation, description and implementation of the include name, version number, and provider. To get this information, you can view the system properties of the JVM (using Java.lang.System.getProperty ())
In the manifest file, I can define a description and implementation version for each package, declare the name, and add a description attribute and implementation attribute, which are
Specification-title
Specification-version
Specification-vendor
Implementation-title
Implementation-version
Implementation-vendor
When it comes to providing a class library or programming interface, it is important to describe the information, as shown in the following example:
manifest-version:1.0
CREATED-BY:JDJ Example
Class-path:mail.jar Activation.jar
name:com/example/myapp/
Specification-title:myapp
specification-version:2.4
Specification-vendor:example.com
Implementation-title:com.example.myapp
Implementation-version:2002-03-05-a
Implementation-vendor:example.com
Package Version Query
After adding the package description in the manifest file, you can use the Java.lang.Package class provided by Java to query for the information about the 3 most basic methods of acquiring the
1.package.getpackages (): Returns all defined package listings in the system
2.package.getpackage (String PackageName): Return to package by name
3.class.getpackage (): Returns the package containing the given Class
Users can get the package information dynamically by using this method.
It is important to note that if no class is loaded in the given package, the package object cannot be obtained

Manifest Tips
Always start with the Manifest-version property
Up to 72 characters per line, if more than one, the continuation line is used
Verify that each line ends with a carriage return or the row will be ignored
If there is a path in Class-path, use "/" to separate the directory, regardless of the platform
Separating main and package properties with blank lines
Use "/" instead of "." To separate the package and class, such as com/example/myapp/
Class ends with A. class, and the package ends with a/

Jar MANIFEST. MF Rollup