This is an example of the crx-package-xsl helper in use, using Ant + XSL to go from CSV > XML > Many XML Files > CRX Package Zip.

Installing packages can delete and modify data. If the filters are wrong the package will happily delete a ton of data. This example is unaffiliated with Adobe.

This project consists of an Ant Build file that will:

• Download dependencies
  • Download SaxonB if not present from the Maven Repository <5MB.
  • Download odu/crx-package-xsl and odu/csv2xml-anttask
• Convert the pages.csv into pages.xml.
• Cleanup the package folder and package.zip file (don't put anything in there).
• Run an XSL Transformation that will convert the pages.xml into multiple xml file in the CRX package layout.
• Zip up the generated files, which should leave a package.zip in the CRX format (tested on AEM 5.6).

This tool requires Ant or WinAnt.

Download or Checkout this project and run the build by typing ant in a Command Prompt or Terminal in the checkout folder.

This package is only tested on the CRX Package Manager on AEM 5.6, this isn't tested with the older CQ Component-based Package manager. It will install content under /content/example but please don't test this on and instance you care about.

The CRX Package format is more complex than meets the eye. The pages.xsl tries to address some of this complexity.

This example package doesn't include the META-INF/vault/ config.xml, nodetypes.cnd, or definition/.content.xml. To the best of my knowledge through trail and error, these files aren't needed for a package to work in AEM 5.6. The crx-package-xsl helper offers options to turn this on if you find them needed for some reason.

The filters for a package are critical to get right, because CRX will likely blow away anything in those filter paths. The crx-package-xsl helper offers the option of specifying multiple filters. These could be generated by XSL or just included as XML elements.

A package that is deeply nested can still need folders and .content.xml files for all of the parents. This example addresses this recurssively without overwriting something that had already created at that level and also without creating a stub .content.xml in a parent, that would really store content at that level.

When your source data structure doesn't mimic the same package structure, it may be difficult to include the children at the same level in .content.xml of the current item.

In this example, I have an illustration of this, the /content/example/.content.xml item has content and lives in the same tree as all of the other nodes. So when creating this, any of the other item paths at the same level also need to be included, but not duplicates (so about, products, and news).

Paths starting with numbers aren't valid XML elements, and also in the underlying JCR I think they are stored differently. The package format converts a nodes 2013 to _x0032_013 but I think this is only necessary for the instance in the parent .content.xml and not a folder name.