Original Specification:

The manifest.xml file will contain the following information:

• the date the archive was packaged
• a short description of what the archive is and/or what its purpose is
• the vendors "source" URL of the package, including format protocol (e.g. cvs, jar, etc)
• the vendors "binary" URL of the package
• a list of build-time dependencies upon which the archive relies as specification name (and optionally specification version, vendor, implementation name, version, vendor)
• a list of run-time dependencies upon which the archive relies as specification name (and optionally specification version, vendor, implementation name, version, vendor)
• the names of and the links to the archive license, change log, bugs, readme, authors.xml, todo list, changes and generic pointers to other documentation-related files
• archive version information
• the package information similiar to that of the manifest.mf file

• the charset of the documentation
• the program that generated the file
• a DTD version number. As the requirements for the manifest.xml file changes, we need to ensure that programs using these files can handle deprecated versions
• target languages as defined in RFC 3066 (BCP47)
• a proper namespace. The manifest namespace will be http://www.cjan.org/schema/2001/Manifest

Entities added to the schema since the original specification:

Proposed entities for manifest.mf

• entities currently in manifest.mf (both Sun's specifications and 3rd party entries), including * the *date the archive was packaged * archive version as per Sun's specification * dependencies as per Sun's war and ear specification (but applies to all artifacts)
• a short description of what the archive is and/or what its purpose is
• purpose-description describes the purpose of the application/artifact
• title-description & icon for application name and icon
• menu / item@arg / label{@xml:lang} for context-menus
• mime / glob@pattern+, comment{@xml:lang}+, action{@arg} for document bindings and file associations
• help@class / arg@value+ | arg@line for help system
• help@uri for help system

Proposed entities for manifest.xml

• the package information similiar to that of the manifest.mf file
• the "source" URL of the package, including format (e.g. cvs, jar, etc)
• the "binary" URL of the package
• the names of and the links to the archive license, change log, bugs, readme, authors.xml, todo list, changes and generic pointers to other documentation-related files

• the charset of the documentation
• the program that generated the file
• a DTD version number. As the requirements for the manifest.xml file changes, we need to ensure that programs using these files can handle deprecated versions
• target languages as defined in RFC 3066 (BCP47)
• a proper namespace. The manifest namespace will be http://www.cjan.org/schema/2001/Manifest

Notes

manifest.xml is normally located inside the archive at /META-INF/manifest.xml. It may be generated by parsing MANIFEST.MF and the general layout of of the archive in addition to asking the user to supply some information such as the descriptions (it may also be possible to glean some details from Gump, Maven or Ant files, if they exist in the archive or in the project). manifest.xml will normally be signed as part of the jar file signing process.

If a jar does not have manifest.xml inside it, the same process can be performed to generate one but it will then need to be signed either by root.cjan.org or the user uploading the jar to CJAN. In this scenario, the manifest.xml is put in the .ZIP file comments section. This has a significant negative impact on the managability of CJAN metadata (as the .ZIP file comments field is only 64K long and is also used to track changes to the manifest.xml file) and is strongly discouraged.