Referenz zu package.xml #

Diese Seite ist für Entwickler, die eine package.xml von Hand schreiben oder ändern. Sie führt jedes Element und Attribut auf, das eZPackage versteht, wie es jedes liest (eZPackage::parseDOMTree()), wie es jedes zurückschreibt (eZPackage::domStructure()) und die Fallen zwischen beidem. Alle Verweise beziehen sich auf kernel/classes/ezpackage.php, sofern keine andere Datei genannt ist.

Inhalt #

1. Wie die Datei gelesen wird
2. Das Wurzelelement
3. Beschreibende Elemente
4. Personen, Paketierung und Geschichte
5. Release-Elemente
6. Dateien
7. Abhängigkeiten
8. Installationsskripte: settings
9. Installations- und Deinstallationselemente
10. Metadaten und Installationsdaten
11. Was verloren geht, wenn der Kernel ein Paket schreibt
12. Verwandte Seiten

Wie die Datei gelesen wird #

• Der Leser sucht die meisten Elemente mit getElementsByTagName(), das ein Element irgendwo unterhalb der Wurzel findet und das erste nimmt. Lassen Sie jedes Element dort, wo der Schreiber es hinsetzt; verwenden Sie einen Elementnamen nicht innerhalb eines anderen Elements wieder (die eine Ausnahme, die der Leser behandelt, ist <version>, das mit XPath als direktes Kind von <package> gelesen wird, sodass <ezpublish><version> nicht im Weg ist).
• Eine Definition ohne Wurzelelement oder ohne nicht leeren <name> ist kein Paket: Sie wird nicht gelesen, und die Paketlisten überspringen sie.
• <version><number>, <version><release> und <type value> müssen jeweils fehlen, leer sein oder ein einfaches Token aus 1 bis 64 Zeichen aus 0-9 A-Z a-z . _ + - sein (isValidDefinitionToken()). Alles andere, und die ganze Definition wird abgewiesen.
• Ein JSON-Paket (package.json) wird zuerst in dasselbe DOM umgewandelt, sodass alles Folgende für beide Formate gilt.

Das Wurzelelement #

<package version="3.5.2" development="false" install_type="install">

Beschreibende Elemente #

Personen, Paketierung und Geschichte #

<maintainers>
  <maintainer><name>...</name><email>...</email><role>lead</role></maintainer>
</maintainers>
<packaging><timestamp>1705211779</timestamp><host>...</host><packager>...</packager></packaging>
<documents><document mime-type="text/plain" name="LICENCE" os="" audience=""/></documents>
<groups><group name="..."/></groups>
<changelog>
  <entry timestamp="..." person="..." email="..." release="1"><change>Creation of package.</change></entry>
</changelog>

Was ein veröffentlichtes Paket ausfüllen muss, steht in Anforderungen an die Dokumentation.

Release-Elemente #

<version><number>6.0</number><release>15-stable</release></version>
<timestamp>1705211779</timestamp>
<licence>GPL</licence>
<state>stable</state>

Dateien #

<simple-files>
  <simple-file key="..." original-path="..." package-path="simplefiles/24ec46f7.jpg"/>
</simple-files>
<files>
  <collection name="default">
    <file-list type="thumbnail" variable-name="thumbnail">
      <file name="thumbnail.png" md5sum="77a7bc0cc6e1e5138ca7a6e39a130307"/>
    </file-list>
  </collection>
</files>

Die erste Datei thumbnail der Sammlung default ist das Bild, das der Setup-Assistent für ein Seitenpaket zeigt (thumbnail-list).

Abhängigkeiten #

<dependencies>
  <provides/>
  <requires>
    <require type="ezpackage" name="sevenx_classes" min-version="5.1"/>
  </requires>
  <obsoletes/>
  <conflicts/>
</dependencies>

Vier Abschnitte mit den Elementen <provide>, <require>, <obsolete> und <conflict>. Der Leser behält jedes Attribut eines Elements. Der Installer handelt nach <require type="ezpackage"> mit name und min-version; siehe Abhängigkeiten und die Installationsreihenfolge. Ein Designpaket von 7x gibt <provide type="ezfile" name="collection" value="default"/> an.

Installationsskripte: settings #

<settings>
  <settings-file filename="install-scripts.php"/>
</settings>

Jeder filename ist eine PHP-Datei im Verzeichnis settings/ des Pakets, die der Schritt zum Anlegen der Websites einbindet. Siehe Installationsskripte in einem Seitenpaket.

Installations- und Deinstallationselemente #

<install>
  <item type="ezcontentclass" filename="class-article" sub-directory="ezcontentclass"/>
  <item type="ezfile" collection="default"/>
</install>
<uninstall>
  <item type="ezcontentclass" filename="class-article" sub-directory="ezcontentclass"/>
</uninstall>

Was jeder Typ tut, steht in Installationselemente und Handler.

Metadaten und Installationsdaten #

• <metadata><entry key="expai.provenance">value</entry></metadata>: freie Zeichenketten, die Werkzeuge mit einem Paket aufbewahren, nur geschrieben, wenn es welche gibt (eZPackage::setMetadata()).
• <install-data><data type="..."><element name="" value=""/><array name="">...</array></data></install-data>: was sich Handler zwischen Installation und Deinstallation merken; vom Kernel geschrieben, nicht von Hand.

Was verloren geht, wenn der Kernel ein Paket schreibt #

domStructure() schreibt die Elemente in einer festen Reihenfolge (name, summary, description, vendor, priority, type, extension, source, ezpublish, maintainers, packaging, documents, groups, changelog, simple-files, files, version, timestamp, licence, state, dependencies, install, uninstall, install-data, metadata). Behalten Sie diese Unterschiede im Kopf, bevor Sie den Kernel eine von Hand erstellte Datei neu schreiben lassen:

Hinweis In 6.0.15 behoben: domStructure() schreibt <settings> (nach <dependencies>) und jedes Attribut eines Abhängigkeitselements. Vorher verlor ein vom Kernel erneut gespeichertes Seitenpaket die Liste seiner Installationsskripte und die min-version seiner Elemente <require>. Die package.xml eines Seitenpakets in seinem Quell-Repository zu bearbeiten, bleibt der klarste Weg, es zu ändern.

• Das Wurzelattribut version wird zu 3.5.2; Attribute, die der Kernel nicht kennt, werden weggelassen.
• <files> wird weggelassen, wenn es keine Datei gibt.
• <settings> wird weggelassen, wenn das Paket keine Einstellungsdatei hat.
• Ein Abhängigkeitselement wird mit type, name, value (wenn nicht leer) und, ab 6.0.15, jedem anderen Attribut geschrieben, mit dem es gelesen wurde (min-version, max-version ...). Vor 6.0.15 wurden diese weggelassen, sodass ein gespeichertes Seitenpaket seine Versionsanforderungen verlor.

Verwandte Seiten #

• Grundlagen der Seitenpakete
• Seitenpakete: hier beginnen
• Pflichtfelder in package.xml
• Versionsnummern
• Paketlizenzen und Semantic Versioning
• Das JSON-Paketformat
• Ihr Seitenpaket beitragen
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.