Maven XAR Plugin
This build tool allows creating XAR files, expanding XAR files, reformatting them and verifying some best practices.
XAR Mojo
To configure it:
- Register a new Maven Lifecycle in your POM:...
<build>
<extensions>
<extension>
<groupId>org.xwiki.commons</groupId>
<artifactId>xwiki-commons-tool-xar-handlers</artifactId>
<version>...version here...</version>
</extension>
</extensions>
... - Create a Maven POM file with the xar packaging: <packaging>xar</packaging>
- Put the wiki pages as XML files in src/main/resources by having directories matching space names. For example:
To use it:
- mvn xar:xar will generate the XAR file
Transformations
It is also possible to perform transformations on the XML files. For example:
Insert a text value
This can work well, for example, to change skin definitions. E.g.:
<groupId>org.xwiki.commons</groupId>
<artifactId>xwiki-commons-tool-xar-plugin</artifactId>
<configuration>
<transformations>
<transformation>
<file>Blog/WebHome.xml</file>
<xpath>/xwikidoc/object/property/itemsPerPage</xpath>
<value>100</value>
</transformation>
<transformation>
<artifact>org.xwiki.platform:xwiki-platform-administration-ui</artifact>
<file>XWiki/XWikiPreferences.xml</file>
<xpath>/xwikidoc/object/property/colorTheme</xpath>
<value>ColorThemes.Mint</value>
</transformation>
</transformations>
</configuration>
</plugin>
Manipulate XML elements
it is possible to remove/replace/insert a complete XML element. Here is an example:
<groupId>org.xwiki.commons</groupId>
<artifactId>xwiki-commons-tool-xar-plugin</artifactId>
<configuration>
<transformations>
<!-- Insert the content of file src/xar/transformations/ckeditor.xml
as child of xwikidoc element in XWiki/XWikiPreferences.xml -->
<transformation>
<artifact>org.xwiki.platform:xwiki-platform-distribution-ui-base</artifact>
<file>XWiki/XWikiPreferences.xml</file>
<xpath>xwikidoc</xpath>
<action>INSERT_CHILD</action>
<xml>src/xar/transformations/ckeditor.xml</xml>
</transformation>
<!-- Remove first attachments from XWiki/XWikiPreferences.xml -->
<transformation>
<artifact>org.xwiki.platform:xwiki-platform-distribution-ui-base</artifact>
<xpath>xwikidoc/attachment</xpath>
<action>REMOVE</action>
</transformation>
</transformations>
</configuration>
</plugin>
Insert Text Content of a File
.xml stay within the same directory and will be ignored unless they are inserted and can thus be edited with an integrated development environment (which brings syntax coloring, auto-completion, reformatting, or validation). Here is an example:
it is possible to insert the text of another project file. This works well to insert complex JavaScript, Velocity or CSS files. These files, if they are not named<groupId>org.xwiki.commons</groupId>
<artifactId>xwiki-commons-tool-xar-plugin</artifactId>
<configuration>
<transformations>
<transformation>
<!-- Insert the content of file src/main/resources/MyApp/config.js
as the value of the property code in the first object of class
XWiki.JavaScriptExtension of the XML file MyApp/Config.xml -->
<action>INSERT_TEXT</action>
<file>MyApp/Config.xml</file>
<xpath>/xwikidoc/object[className[text()='XWiki.JavaScriptExtension']]/property/code</xpath>
<content>src/main/resources/MyApp/config.js</content>
</transformation>
</transformations>
</configuration>
</plugin>
Insert an Attachment
it is possible to insert the content of another project file as an attachment in Base64 encoding just as XWiki would do it in an XML file of a XAR. You can use this to insert files with the same name edited somewhere else. Doing so, it also updates the filesize attribute. Here is an example:
<groupId>org.xwiki.commons</groupId>
<artifactId>xwiki-commons-tool-xar-plugin</artifactId>
<configuration>
<transformations>
<transformation>
<!-- Insert the content of file src/main/resources/MyApp/testcolors.xls
as the attachment of the page TestDocumentList of the space MyApp -->
<action>INSERT_ATTACHMENT_CONTENT</action>
<file>MyApp/TestDocumentList.xml</file>
<content>src/main/resources/MyApp/testcolors.xls</content>
</transformation>
</transformations>
</configuration>
</plugin>
Documents types
It's possible to indicate in the pom.xml the type of a each document. That way the package.xml will be generated automatically but will take into account information it cannot really deduce from the documents XML files.
<groupId>org.xwiki.commons</groupId>
<artifactId>xwiki-commons-tool-xar-plugin</artifactId>
<configuration>
<entries>
<entry>
<document>Main.WebHome</document>
<type>home</type>
</entry>
<entry>
<document>Some.Demo.Page</document>
<type>demo</type>
</entry>
<entry>
<document>MyApplication.MyConfiguration</document>
<type>configuration</type>
</entry>
</entries>
</configuration>
</plugin>
Format Mojo
To use it:
- mvn xar:format will perform some cleaning of your XML files, namely:
- Indent lines (using 2 space characters)
- Set author, contentAuthor, creator and attachment authors to be xwiki:XWiki.Admin
- Set version to be 1.1
- Set minorEdit to be false
- Remove any content of the defaultLanguage element unless the document has translations. Indeed, if a document has translation we assume it means the document is not a technical document and thus we set the default language to be English. This allows the XWiki SOLR Search to return results when the English language is selected in language facet.
- Remove any content of the comment element
- xwiki-commons-tool-verification-resources JAR. License headers will be checked if the formatLicense configuration parameter is set to true:<plugin>
<groupId>org.xwiki.commons</groupId>
<artifactId>xwiki-commons-tool-xar-plugin</artifactId>
<version>${commons.version}</version>
<configuration>
<!-- Add missing license headers by default -->
<formatLicense>true</formatLicense>
</configuration>
</plugin> Add any missing license header by using the license defined in - technicalPages configuration element as in:<plugin>
<groupId>org.xwiki.commons</groupId>
<artifactId>xwiki-commons-tool-xar-plugin</artifactId>
<version>${commons.version}</version>
<configuration>
<technicalPages>
<technicalPage>.*/.*Translations\.xml</technicalPage>
</technicalPages>
</configuration>
</plugin> Technical pages are marked hidden. To mark a page as technical use the - date, creationDate, contentUpdateDate or attachment date fields, regardless if they have empty values or not. This is done because it's causing confusion for users to install pages that are created in 2005/2009/etc. so we should avoid committing dates on git that users might end up installing.
- Can be disabled for individual pages with either -Dxar.dates.skip.documentList=Space1.Subspace2.Page1,Space2.Subspace2.Page2,etc. (system property) or <skipDatesDocumentList>Space1.Subspace2.Page1,Space2.Subspace2.Page2,etc.</skipDatesDocumentList> (plugin configuration parameter).
- Can be disabled for all pages in the xar with either -Dxar.dates.skip=true (system property) or <skipDates>true</skipDates> (plugin configuration parameter).
Remove any - technicalPage and contentPage entries in the plugin configuration now accept a regex that will be tested on the full path of the file. Before the regex was tested only on the file name. This allows supporting spaces. The
Verify Mojo
This is used to fail the build if the XML pages don't conform to the following rules:
- Verify that the encoding is UTF-8
- Verify that author, contentAuthor, creator and attachment authors are set to xwiki:XWiki.Admin
- Verify that the parent field is not empty (except for Main.WebHome)
- Verify that version is set to 1.1
- Verify that comment is empty
- Verify that minorEdit is set to false
- Verify that the defaultLanguage is empty for technical documents or the configured language in the mojo (by default en, it's configurable in the <configuration>, for example <defaultLanguage>fr</defaultLanguage>) for documents having translations (which we assume are not technical documents). If a page has translations then we consider it as a content page, otherwise we consider it a technical document. Note that since version 7.1 it's possible to provide a white list of content and technical pages (when both are specified and matching, content pages take precedence since 7.3; before 7.3 technical pages used to take precedence). For example:<plugin>
<groupId>org.xwiki.commons</groupId>
<artifactId>xwiki-commons-tool-xar-plugin</artifactId>
...
<configuration>
...
<!-- Consider all pages named *Translations as content pages by default -->
<contentPages>
<contentPage>.*/.*Translations\.xml</contentPage>
</contentPages>
<!-- The EditTranslations page is not a Translation page and thus not a content page! -->
<technicalPages>
<technicalPage>.*/EditTranslations\.xml</technicalPage>
</technicalPages>
</configuration>
</plugin> - (optional) Verify that the XML files contain license headers (if the formatLicense configuration property is set to true).
- Verify that Technical pages are set as hidden. See the Format mojo above.
- <plugin>
<groupId>org.xwiki.commons</groupId>
<artifactId>xwiki-commons-tool-xar-plugin</artifactId>
...
<configuration>
...
<titles>
<!-- Verify that all WebPreferences pages have the same title for consistency -->
<property>
<name>.*WebPreferences</name>
<value>\$services\.localization\.render\('admin.preferences.title'\)</value>
</property>
</titles>
</configuration>
</plugin> Verify that defined pages have a specific matching title. For example: - XWiki.TranslationDocumentClass xobject) are using the plain/1.0 syntax. Verify that Translations pages (i.e. documents with a
- translationVisibilitySkip configuration option (or xar.verify.translationVisibility.skip on the command line). Verify that Translations pages don't have a GLOBAL or USER visibility (USER makes no sense and GLOBAL would require Programming Rights, which is an issue in farm-based use cases). This check can be ignore by using the
- Verify that attachments have a mimetype set. If the mimetype is missing then the attachment won't be filterable in the attachment view in Page Index.
- date, creationDate, contentUpdateDate or attachment date fields are not specified, thus risking to import pages with stale dates.
- Can be disabled for individual pages with either -Dxar.dates.skip.documentList=Space1.Subspace2.Page1,Space2.Subspace2.Page2,etc. (system property) or <skipDatesDocumentList>Space1.Subspace2.Page1,Space2.Subspace2.Page2,etc.</skipDatesDocumentList> (plugin configuration parameter).
- Can be disabled for all pages in the xar with either -Dxar.dates.skip=true (system property) or <skipDates>true</skipDates> (plugin configuration parameter).
Verify that any - technicalPage and contentPage entries in the plugin configuration now accept a regex that will be tested on the full path of the file. Before the regex was tested only on the file name. This allows supporting spaces. The
Example usage:
<groupId>org.xwiki.commons</groupId>
<artifactId>xwiki-commons-tool-xar-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
To skip the execution of the verify mojo, you can use the property xar.verify.skip with the value true.
UnXAR Mojo
To configure it:
<groupId>org.xwiki.commons</groupId>
<artifactId>xwiki-commons-tool-xar-plugin</artifactId>
<configuration>
<groupId>...group id of XAR artifact to expand...</groupId>
<artifactId>...artifact id of XAR artifact to expand...</artifactId>
<outputDirectory>${project.build.outputDirectory}</outputDirectory>
<includes>
<include>Space/Page.xml</include>
...
</includes>
<excludes>
<exclude>Space/Page.xml</exclude>
...
</excludes>
</configuration>
</plugin>
To use it:
- mvn unxar will expand the XAR file