package.xml format
Every package directory has a package.xml at its top: the package's name, version, type, maintainers, dependencies and the list of items to install. A package can also be kept in the JSON format (package.json), which mirrors the XML element for element; see the JSON package format.
The main elements
An abbreviated package.xml of the shipped package sevenx_classes:
<?xml version="1.0" encoding="utf-8"?>
<package version="3.5.2" development="false" install_type="install">
<name>sevenx_classes</name>
<summary>sevenx content classes</summary>
<vendor>7x</vendor>
<type value="contentclass"/>
<maintainers>...</maintainers>
<packaging><timestamp>1705211775</timestamp><host>...</host></packaging>
<version><number>6.0</number><release>10-stable</release></version>
<licence>GPL</licence>
<state>stable</state>
<dependencies>
<provides>
<provide type="ezcontentclass" name="contentclass" value="article"/>
</provides>
<requires/>
</dependencies>
<install>
<item type="ezcontentclass" filename="class-article" sub-directory="ezcontentclass"/>
<item type="ezcontentclass" filename="class-folder" sub-directory="ezcontentclass"/>
</install>
</package>
| Element | Meaning |
|---|---|
| name | The package name: letters, digits, _ and -, not starting with -. It is also the directory name. |
| vendor | Decides the repository the package is imported into (local without one). |
| type | The package type (Package types). |
| version, state, licence, maintainers, changelog, documents | What the package page shows about the package. |
| dependencies | provides, requires (<require type="ezpackage" name="..."/> for another package), obsoletes, conflicts. |
| install, uninstall | The items to install, and to remove when uninstalling. One <install> element per file. |
Items to install
Each <item> of <install> is installed in the order it is listed, by the handler of its type.
| Attribute | Value |
|---|---|
| type | The item type, which chooses the handler: ezcontentclass, ezcontentobject, ezextension, ezinstallscript, ezfile (also ezini, ezdesign, eztemplate, ezthumbnail), eziniaddon, ezsql, expstatictarget |
| filename | The XML file that describes the item, without .xml |
| sub-directory | The directory of that file inside the package |
| name, os | Optional: a name for the item, and an operating system it is limited to |
The type names are mapped to handler classes in package.ini [PackageSettings] HandlerAlias[]; the handlers are in kernel/classes/packagehandlers/. An extension can add its own handler there.
Example: three classes described in myclassdir/class-myarticle.xml, class-myfolder.xml and class-myproduct.xml are installed in this order:
<install> <item type="ezcontentclass" filename="class-myarticle" sub-directory="myclassdir"/> <item type="ezcontentclass" filename="class-myfolder" sub-directory="myclassdir"/> <item type="ezcontentclass" filename="class-myproduct" sub-directory="myclassdir"/> </install>
Checking a package
Validate on a package's page checks it as an upload is checked. On the command line, php ezpm.php validate <source> checks a package in either format (an archive, a directory or a package name) without importing it, and php ezpm.php check <package> shows what installing it would meet on the site, by remote ID, without writing anything. xmllint --noout package.xml checks that the file is well formed.
More
- Custom install scripts: the ezinstallscript item.
- Packages, sections 1 and 6.
Contributors
- Svitlana Shatokhina
- Geir Arne Waaler
- dexen deVries Commenter
- Xavier Commenter
- Graham Brookins Updated Maintainer
Comments (2 historical)
Written by readers of the earlier documentation sites, kept as they were.
DTD of package.xml
dexen deVries ·
Hi, where do i find DTD for package.xml? (I hope there is one >_>;;)
Re: DTD of package.xml
Xavier ·
Wouldn't bet to high on that..