Starting in version4.2, it's now possible (and recommended) to use XML-based Extension building. The main advantage is that all extension dependencies can be analyzed before the building starts and before we have loaded any extension code at all. Also, this means that all other extensions that are required to run a particular extension that you are actually interested in can be built on the fly. Gone is the tedious hassle of trying to push the appropriate build buttons in the correct sequence!
The extension.xml file found in the directory of the extension contains basic and vital information about the extension itself. This information will then be used to create the ExtensionInfo object, and are stored in the tag elements of the xml file:
The tag elements include:
Tag | Description |
<main> |
The main package which contains extension.cm. |
<name> |
The official name of the extension. |
<type> |
|
<version> |
Version number. Important for checking if old code is used, and updating. |
<parent> |
Establish which extension to be under. |
<packages> |
List of directories where package.cm is found WITHIN the main extension directory. NOT extensions on their own (they don't have their own extension.xml) |
<extension-dependencies> |
List of extensions outside the current extension directory which will be automatically enabled when the current extension is enabled. (has version policy checks, makes dependencies unsnoozable) |
<embedded-catalogs> |
db3 files to enable and download/embed when the extension is enabled. |
<security-delegates> |
Which extension to delegate permissions from. (Example: if a child extension only needs the permissions/license of the parent extension, the child extension would list the parent extension as the security-delegate) |
<security-requirements> |
Other permission(s) that are needed to enable this extension. |
<category> |
Category of the extension. (currently have no inherent use) |
<group> |
Group of the extension. (currently have no inherent use) |
<bundle-install> |
Same as <extension-dependencies> but without version policy checks, and dependencies are still snoozable. |
<bundle-uninstall> |
Supposed to disable extensions on enabling. But is now useless. |
<unsupported-platforms> |
Currently have no inherent use. |
Example
<?xml version="1.0" encoding="iso-8859-1"?> <extension-info> <main>custom.fika.office</main> <name>Fika: Office</name> <group>[fika]</group> <version>11.0.18.0</version> <parent>custom.fika</parent> <packages> <package id="custom.fika.office" /> <package id="custom.fika.office.reports" /> </packages> <extension-dependencies> <dependency id="cet.designer" /> <dependency id="cm.core" /> <dependency id="cm.core3D" /> <dependency id="cm.abstract" /> <dependency id="cm.abstract.tools.digitalSwatch" /> <dependency id="cm.abstract.tools.apply" /> <dependency id="cm.abstract.office" /> <dependency id="cm.abstract.surface" /> <dependency id="cm.abstract.tools.apply" /> <dependency id="cm.abstract.tools.queryDialog" /> <dependency id="cm.abstract.tools.digitalSwatch" /> <dependency id="custom.fika" /> <dependency id="cm.abstract.dataSymInterface" /> <dependency id="cm.abstract.dataSymbol" /> </extension-dependencies> <security-delegates> <delegate id="custom.fika" /> </security-delegates> <embedded-catalogs> <catalog cid="643" db-file="configuraFIKA" specific-product-catalogs="FIKA" ignore="yes" /> <catalog cid="1531" db-file="configuraFIKA" specific-product-catalogs="FIKA" wait-for-all-files="yes" /> </embedded-catalogs> </extension-info>
Comments
0 comments
Please sign in to leave a comment.