Importing and Exporting Content

CRX offers a set of tools for importing and exporting content to and from the repository. These tools support a number of different file formats to store content outside of the repository and several ways of transforming JCR content (hierarchy of nodes and properties) into these files. The following table summarizes available tools and supported formats.

The following sections describe tools available in more details.

Tool Format Remarks
Package Manager   Advanced tool for defining, creating, and managing content packages. Content packages can be uploaded to and downloaded from the repository, as well as created and downloaded on-the-fly. Package definition supports multiple node hierarchies and advanced content filtering for maximum flexibility.
  Content Package Content Package format, based on CRX VaultPackaging content serialization technology. It provides a full mapping of JCR content, including nodetype definitions and flexible filtering, into a file system. Content is represented as a hierarchy of folders and files and packed up in a standard ZIP archive.
Content Loader
Content Zipper
  Tools for importing and exporting JCR content using various formats.
  XML Sys View A system view of the repository. This view perfectly mirrors the state of the repository, but the resulting XML code can become fairly complex.
This is a mapping defined by the JCR standard.
  XML Doc View A document view of the repository. Simpler than the system view, this view is optimized for clarity and simplicity, but it may not support some advanced repository features.
This is a mapping defined by the JCR standard.
  CRX Package Stores the same information as the system view, but uses Day's proprietary CRX package format (binary). This format is faster and smaller, but you can only use it with CRX.
  ZIP file Stores files and folders in a compressed form (popular ZIP archives). All nodes must have the node type nt:file or nt:folder (other node types might be handled specially). This format might not support more advanced repository features.

The choice of the import/export tool, and the format used, depends on the usage scenario and needs, as follows:

Use Case Recommended tool/format
Importing/exporting content with full support for JCR features - Package Manager
- Content Loader/Zipper with XML System view or CRX package formats
Flexible package definition and management - Package Manager
Moving data between different JCR-compliant repositories - Content Loader/Zipper with XML system view format
Quick loading/saving of files and folders - Content Loader/Zipper with ZIP format
- Note: WebDAV or CIFS can be used to achieve this directly from the desktop.
Getting JCR standard XML mapping of content - Content Loader/Zipper with XML system view or XML document view format

CRX Package Manager

This section describes how to use the following in CRX:

  • Package Manager, which you use to manage the packages in your local CRX installation, including how to upload, create, and download packages. It also explains what packages are and how to provide permissions to them.
  • Package Share, which lets you find, share, and download packages, components, and hotfixes from the Day server. You can also upload packages for internal company use.

Note

CQ5 and CRX both have their own Package Manager user interfaces. These offer the same set of basic functionalities, but with minor differences in the options offered and each with a distinctive look and feel. They do use the same core package management module.

Users of CQ5 should generally use the CQ5 package manager unless explicitly instructed to do otherwise in the CQ5 documentation. This document is intended for CRX users.

What are Packages?

Packages can include content and project-related data. A package is a zip file that contains the content in the form of a file-system serialization (called "vault" serialization) that displays the content from the repository as an easy-to-use-and-edit representation of files and folders.

Additionally, it contains vault meta information, including a filter definition, and import configuration information. Additional content properties can be included in the package, such as a description, a visual image, or an icon that are not used for package extraction; these properties are for the content package consumer for informational purposes only.

You can perform the following actions with packages:

  • Create new packages
  • Modify existing packages
  • Build packages
  • Upload packages (CRX does not automatically install packages after uploading)
  • Install packages
  • Download packages, such as hotfixes, from the Package Share library
  • Upload packages to the internal company section of the Package Share library
  • Download packages from CRX to a local machine
  • Apply package filters
  • View package information
  • Uninstall packages, which reverts to the snapshop of in-repository content at the time of the last installation.
  • Delete packages, which deletes the zip package from the repository.

As a package can contain an icon, Day uses the following conventions for official packages:

Note

To avoid a mix-up, use a descriptive icon for your package and do not use one of the official Day icons.

   Official Day Hotfix package
 
 Official Day CRX/CQ5 Installation or Extension package
 
Official Feature packs

Using the Package Manager

The Package Manager manages the packages on your local CRX installation. You access the Package Manager from the welcome screen located at http://<server name>:<port number>/crx/packmgr/. Click Package to open the Package Manager.

file

In the Package Manager, you can sort and filter your packages by using the selections in the Sort By, Show, and Groups areas in the left-hand frame. To search for packages, enter the name (or part of a name) of a package in the Search field and click the magnifying glass.

Note

You may need to log into the repository to see available packages for your user. Also, if you make changes, logging in means that the action includes information about who performed the action, for example "last installed by john."

file

In this example, all packages display in the right-hand frame.The buttons on the right side indicate the status of the package and provide quick access to the action most likely to be executed next:

Status Description
Build The package is new and has not yet been built.
OK The package is installed. No modifications have been made to the package since the last build.
Share The package has been built and can be shared on Day's Package Share.
Install The package was downloaded from package share or manually uploaded and was not yet installed on the local system.
Rebuild The package has been modified from the last build and can be rebuilt.

To open a package, click its icon to expand it. All possible commands for packages are available from the toolbar. Package Manager functionality is covered in detail in this documentation.

file

Hover your mouse over the status indicators for more information. The first square indicates whether the package is installed, and when it has been installed. The second square indicates whether the package is modified.

file

Note

A package is considered modified if metadata such as name, description, etc, changed or if the filters have been adjusted, but the zip package has not been rebuilt. 

Creating Packages

You create packages to share with other users or to install content on multiple CRX instances.

When you create a package, you can add it to a group. Doing so, lets you define the location and grouping of your package, and the package will be placed in the corresponding group (location) when shared on Package Share.

To create a package in CRX:

  1. Open CRX and log in as administrator and click Package. The Package Manager opens.

  2. Click Create.

    file
  3. Enter the name of the package and either enter a new group name or select the group name from the drop-down menu and click OK. CRX creates the package in the selected group. If the group didn't exist, it creates a group for you.

    After you create a package, you must add a filter definition and build the package before you can share it with others. You can also customize or edit other aspects of the package before building it.

Editing Packages

After you create a package, you can make a variety of changes to it, including renaming the package, changing the filter definition, changing the package icon, and adding various additional information described in this procedure.

To modify the contents of a package:

  1. In the Package Manager, click the icon or the name of the package you want to modify (or build) to expand it, then click Edit.

    file

    Note

    After you make any changes to the package, be sure to click Save.

  2. In the General tab, you can enter the following:

    Field Description
    Name Enter a new package title.
    Group Select a group from the drop-down menu. You can also enter the name of a new group manually in the text field to create it.
    Version Create a custom version for each package (optional). A separate, automatically incremented build number will always be added to your version information.
    Description Enter additional information that displays with the package, such as a short overview of content, features or fixed issues that this package contains. This description is shown alongside the package in the list of packages on the package share."
    Thumbnail
    Click Browse to navigate to another image to use for a thumbnail. Day recommends that you use custom images for packages you create (rather than the Day package icons)
    file
  3. Click the Filters tab to add filter definitions. Filters determine which content is included in the package. Filter definitions are described in detail in the Adding Filter Definitions section.

  4. Click the Dependencies tab to enter the following information:

    Field Description Format/Example
    Tested with

    Enter additional information about the product name and version that the selected package is compatible with.

    This is for informational purposes only.

    CRX 2.1
    Fixed issues

    Enter any fixed bugs (one bug per line) with this package.

    This is for informational purposes only.

    12455

    12877

    Requires

    Select the Admin check box to inform users they would need administrative privileges before they can install the selected package.

    Select the Restart check box to inform users they would need to restart their instance of CRX after installing the package.

    Depends on
    Lists dependency information that needs to be respected whenever other packages are necessary to let the current package run as expected. This field is important when using hotfixes. Add dependencies by clicking the Plus button.

    groupId:name:version

    my_company/hotfix:update1234:1.0

    Replaces
    Replaces the information for the package that becomes obsolete when you install this package. Before installing, check that this package includes all necessary content from the obsolete package so no content is overwritten. Add more packages to the list by clicking the Plus button.
    groupId:name:version
    file

    Note

    Dependency information is not enforced or verified by the system, it is used for information only. It is intended to help package providers and users (system administrators) to understand and verify package dependencies.

    However, future CRX versions might use dependency information for automating dependency management.

  5. Click the Provider tab to enter additional information about the provider (author) of the package, and the package itself:

    Field Description Format/Example
    Name
    Enter the provider's name
    Day Software
    URL
    Enter the provider's URL
    http://www.day.com
    Link Package-specific link to a provider page http://www.day.com/mypackage.html
    file
  6. Click Save to save your changes.

Adding Filter Definitions to Packages

The filter defines what content is included in the package. Each filter definition contains a root path and optionally a set of include and/or exclude regexp patterns.

CRX allows you to add include and exclude rules to the path so that you can include or exclude certain content. The following table provides examples of how you could apply filters and rules.

Expected result Root Path Rules
To include all scripts and content of my application /apps/myapp
/content/myapp
None
None
To include all scripts of my application but the forms component /apps/myapp Exclude /apps/myapp/components/form(/.*)?

Note

In the second example, the form component is not included in the package. If such a component already existed when installing the package, CRX would not remove it, because it is not defined by the filters. In the first package, an existing form component would be removed because it is covered by the filter.

The patterns are applied against the paths of the nodes (rather than the properties).  

When building the package, all the content defined by each filter is included. When extracting the package, all existing content that matches the filter is removed or replaced. 

To add a filter definition to a package:

  1. In the Package Manager, click the icon or the name of the package you want to modify (or build) to expand it, then click Edit.

  2. Click the Filters tab.

  3. Click Add filter.

    file
  4. In Root Path, click the magnifying glass to navigate to the folder that contains the content you want to include in the package. Alternatively, type in the path manually (path auto-completion will assist in this case). Click Done when finished. CRX adds the path to the filter definition. (You can add additional filters by clicking Add filter.)

  5. For each filter, you can also add rules in the form of an include or exclude regexp pattern. Add more rules by clicking Add Rule. Remove rules by clicking the Minus symbol -. The order of how the rules appear does matter. Order the rules with the Up or Down arrows. See the include/exclude examples and commonly used regexp patterns. Click Done when finished editing filters.

    file
  6. Click Save to save your changes. If necessary, rebuild the package.


Include and Exclude Examples

The following tables describes include and exclude filters and provides examples:

Filter Description Example
include

Including a directory means to include that directory and all the child files and folders in that directory, but not other files and directories.

Syntax is "include:" followed by an XPath expression to select all the nodes that you want to include. You select Include from the drop-down menu. (You do not need to add the : before the XPath expression in the GUI.)

include:/libs/sling/install(/.*)?
exclude

Excluding a directory means to exclude that directory and all child files and folders in that directory.

Syntax is "exclude:" followed by an XPath expression to select all the nodes that you want to exclude. You select Exclude from the drop-down menu. (You do not need to add the : before the XPath expression in the GUI.)

exclude:/libs/cq/widgets/test(/.*)?

When adding filters, order matters. Filters are executed from the top down. You can reorder the filters and preview the content to ensure the correct content is added.

Commonly Used Patterns

Comment Regexp Pattern
Match all foo.txt files: .*/foo\.txt$
Match child nodes: /foo/.*
Match direct child nodes: /foo/[^/]*$
Match node and child nodes: /foo(/.*)?

Removing Content With Packages

Sometimes, it might be useful for a content package to be able to remove some content, in addition to the usual adding or overwriting of existing content.

If a package includes a filter for certain piece of content, but this content is not present in the actual package, and this content is present in the system prior to installation of the package, the content from the system will be removed from during package installation.

This is useful, e.g., for update packages that might add a new version of a bundle jar (eg. mybundle-2.0.jar) and should ensure to remove the old version (eg. mybundle-1.0.jar).

Previewing Package Content

After you have defined all the filters, you can preview what the package content would be before building it. You can preview the Package Contents and the Package Coverage.

Package contents shows what is inside the package. Package coverage shows what is in the content covered by package filters or what will be included in the built package.

To preview a package:

  1. In the Package Manager, navigate to the package you want to build.
  2. Click the icon or the name of the package you want to modify (or build) to expand it.
  3. In the More drop-down menu on the toolbar, select either Contents or Coverage. CRX previews the coverage or contents.

In the bottom frame, you see a list of paths of nodes that are included as a result of the filter.

Building Packages

After you have defined the package, you need to build it. This will collect all the content defined by the filters from the repository, the package metadata, and package it up into a distributable and deployable package.

Every time you change a package definition, you must rebuild the package to capture your content changes. If you want to improve package metadata but do not want to update the content, use Rewrap.

To build the package:

  1. In the Package Manager, navigate to the package you want to build.
  2. Do one of the following:
    • Click the icon or the name of the package you want to modify (or build) to expand it. Click Build
    • In the package status, click Build or Rebuild if it is ready to be built.
  3. CRX confirms that you want to package the content. Click OK.

In the bottom frame, you see the progress of the build process.

Note

Rebuilding a package includes the current package definition (metadata) and content from repository in the package.

Rewrapping a package includes the current package definition (metadata) and reusing the content already in the package. Rewrapping does not update the content of the package. Use rewrap if you have content that has been verified, but you want to improve package metadata, for example, by changing the icon and then rewrapping the package without changing the content.

Downloading Packages

After a package is built, you can download it by clicking Download Package.

To download a package:

  1. In the Package Manager, navigate to the package you want to build.
  2. Click the icon or the name of the package you want to download to expand it.
  3. Click Download or click the linked name of the package to download it to a location you specify.

Deleting Packages

Deleting the package removes the actual package from the system (it will not be visible in the package manager any more). This action does not alter the content created during installation of that package.

You can delete any existing packages.

To delete a package: 

  1. In the Package Manager, navigate to the package you want to delete.
  2. Click the icon or the name of the package you want to delete to expand it.
  3. In the More drop-down menu of the toolbar, select Delete.
  4. CRX confirms that you want to delete the package. Click OK to delete.

Uploading Packages

Any packages that you successfully upload from your local disk to the package manager appear in the package list. After you have uploaded a package, you can install the content into the CRX repository. You can also share it using the Package Share.

To upload the package:

  1. In the Package Manager, click Upload Package.

  2. Navigate to the package and click OK.

    file
  3. Click Upload. CRX uploads the package and the package appears in the package list.

Installing Packages

 To install a package: 

  1. In the Package Manager, navigate to the package that you want to install.
  2. Click the icon or the name of the package you want to install to expand it.
  3. Click Install. If you need to configure advanced installation options, click Advanced Options to expand the selection.
  4. Confirm that you want to install the package to install the contents.

Note

You can also run a Test Install (without actually installing the contents) and reinstall content if necessary. Test Install is available from the More drop-down menu. Reinstall displays on the toolbar instead of Install when a package has already been installed.

file

Note

When a package is installed, it creates a "snapshot" of the current content it is about to overwrite. Technically, it just creates an internal snapshot package using the same filter definition as the package to be installed. This snapshot is then used by other package manager functionalities, like Uninstall.

Please note that the snapshot is not recreated when re-installing the package.

The internal snapshot package is not intended to be used by application code, it is a way to implement the "uninstall" feature. Future versions might use a completely different implementation.

Advanced Installation Options

When installing packages, you can specify advanced installation options that include the following:

  • Specifying the save threshold
  • Enabling automatic extraction of sub-packages
  • Specifying access control handling

They are available in the Install Package dialog, after clicking Advanced Settings.

file
Option Description Default
Save Threshold

Package manager saves package nodes in batches when installing packages. This number specifies the approximate number of nodes in a batch that is saved to persistent storage in one transaction.

You might need to increase the number in case of concurrent modification exceptions while installing packages.

1024
Extract Subpackages

If a package contains sub-packages, this options causes automatic extraction (installation) of sub-packages to the repository.

If this option is unselected, subpackages are only saved to the repository, but left uninstalled. You can install them manually after the installation of the main package.

Yes
Access Control Handling

Packages might contain Access Control information (ACL) for the content. This option provides various ways to manage this information during installation. Note that the "information in the repository" concerns only the repository content covered by package filters.

Ignore:  Ignores the ACL information containted in the package.

Overwrite: Overwrites the ACL information in repository with the one in the package.

Merge: Tries to merge the ACL information in the repository with the one in the package.

Clear: Clears the ACL information in the repository alltogether.

Merge

Uninstalling Packages

Uninstalling the package means that the content present in the repository just before the initial installation of that package will be restored and saved into the repository.

To uninstall the contents of a package: 

  1. In the Package Manager, navigate to the package that you want to uninstall/remove.
  2. Click the icon or the name of the package you want to uninstall to expand it.
  3. Click Uninstall.
  4. Confirm that you want to uninstall the package contents.

Note

The current implementation of package uninstallation uses the snapshot package created before package installation. It restores the content from that package into the repository.

Managing Packages on the Command Line

An HTTP service interface is available and allows for managing packages using command-line clients like curl or wget or automated scripts.

Note

The Legacy interface is still supported in CRX 2.1. For a list of 2.0 commands, see Managing Packages on the Command Line in 2.0.

The following operations are supported in CRX 2.1:

  • uploading packages
  • creating packages
  • deleting packages
  • downloading packages
  • performing a dryrun
  • previewing package
  • listing packages (contents)
  • building packages
  • rewrapping packages
  • installing packages
  • uninstalling packages

To trigger these operations, you send requests using the command line client to the CRX repository. The response is sent back either in plain HTML, JSON, or in a script.

Package Manager HTTP Service API

CRX 2.1 has a new Package Manager HTTP Service API interface located at http://localhost:7402/crx/packmgr/service/<response-format>/<package-jcr-path>?cmd=<command>. The legacy interface is still supported:

  URI Example
Legacy interface (CRX 1.4 - 2.0, still supported in 2.x)

http://localhost:7402/crx/packmgr/service.jsp

(GET and POST, depending on command)

POST http://localhost:7402/crx/packmgr/service.jsp?cmd=inst&name=mycontent.zip
CRX 2.1 interface

http://localhost:7402/crx/packmgr/service/*.json/

http://localhost:7402/crx/packmgr/service/console.html/*

(POST only, all operations have side-effects)

POST http://localhost:7402/crx/packmgr/service/etc/packages/mycontent.zip?cmd=install

In CRX 2.1, the API URL is as follows:

http://localhost:7402/crx/packmgr/service/<response-format>/<package-jcr-path>?cmd=<command>

Response formats

Response formats (<response-format>) can appear either as a plain HTML response, JSON response, or as a script.

JSON

For a json response, without the streaming of contents or logs:

http://localhost:7402/crx/packmgr/service/*.json, for example as http://localhost:7402/crx/packmgr/service/.json/etc/packages/mycontent.zip?cmd=install

* can be anything or it can be left out as in the previous example.

The following parameter is available for a JSON response:

Parameter Description
jsonInTextarea=true Wraps JSON inside text area for use in iframes for ajax clients.

An example JSON response might look like this:

{
// indicating whether the package operation succeeded or not
"success": true,

// short message, contains error message if success=false
"msg": "Package created.",

// path to the package (might have changed, eg. upon create)
"path": "/etc/packages/folder/mypackage.zip"
}

HTML

For a plain HTML response:

http://localhost:7402/crx/packmgr/service/console.html, for example as http://localhost:7402/crx/packmgr/service/console.html/etc/packages/mycontent.zip?cmd=install

Script

For a response that is a mixed stream and client-side javascript callback response:

http://localhost:7402/crx/packmgr/service/script.html, for example as http://localhost:7402/crx/packmgr/service/script.html/etc/packages/mycontent.zip?cmd=install

The following parameters are available for a script.html response:

Parameter Description
callback=myCallbackFunc

Client-defined javascript function that will be passed as a single object with these properties:

  • msg - HTML-formatted log message
  • pid - pid taken from request parameter
  • share:true, status, progress, max - and other properties for share commands
pid=XYZ Client-defined ID to identify this response in the client-side callback.

Packages to operate on

Packages (<package-jcr-path>) to operate a given command must be the path of the package in the repository, which is typically /etc/packages/<group>/<package-name>.zip.

Commands

All commands (<command>) are given via the cmd parameter. For example:

http://localhost:7402/crx/packmgr/service/console.html/etc/packages/mycontent.zip?cmd=install

Note

If you are installing packages, you need to log in. In curl, you can pass credentials via "-u admin:admin."

The following examples show how to manage packages as administrator (admin/admin) on a CRX repository installed at the port 7402 of the localhost by using curl.

Uploading packages

To upload a package, use the following command in your terminal:

curl -u <uid>:<pwd> -F package=@<package.zip> http://localhost:7402/crx/packmgr/service/.json/?cmd=upload

Parameter Description
package File parameter with the zip package binary (required)
force Set to true to force upload, that is, overwrite and existing package of the same name. (optional)

For example:

Creating packages

To create a package, use the following command in your terminal:

curl -u <uid>:<pwd> -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/mycontent.zip?cmd=create -d packageName=<name> -d groupName=<name>

Parameter Description
packageName Name of the package to create (required)
groupName Name of the group, for example, mycompany (required)

For example:

curl -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/my_packages?cmd=create -d packageName=testpackage -d groupName=day
{"success":true,"msg":"Package created","path":"/etc/packages/day/testpackage.zip"

Deleting packages

To delete a package, use the following command in your terminal:

curl -u <uid>:<pwd> -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/mycontent.zip?cmd=delete

For example:

curl -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/my_packages/package.zip?cmd=delete
{"success":true,"msg":"Package deleted"}

Performing a dryrun installation

To perform a dryrun installation of a package, use the following command in your terminal:

curl -u <uid>:<pwd> -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/mycontent.zip?cmd=dryrun

For example:

curl -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/my_packages/package.zip?cmd=dryrun
{"success":true,"msg":"Package installed (dry run)"}

Previewing packages

To preview a package, use the following command in your terminal:

curl -u <uid>:<pwd> -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/mycontent.zip?cmd=preview

For example:

curl -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/my_packages/testpackage.zip?cmd=preview
{"success":true,"msg":"Coverage dumped."}

Listing package contents

To list package contents, use the following command in your terminal:

curl -u <uid>:<pwd> -X POST http://localhost:7402/crx/packmgr/service/console.html/etc/packages/mycontent.zip?cmd=contents

For example:

curl -X POST http://localhost:7402/crx/packmgr/service/console.html/etc/packages/my_packages/testpackage.zip?cmd=contents
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><head>
<style type="text/css">
body {
background-color: white;
font-family: verdana, arial, sans-serif;
font-size: 12px;
white-space: nowrap;
}
div {
font-family: courier, monospace;
font-size: 11px;
}
</style>
<script type="text/javascript">
function onStatus(pid, stat, p, max, msg) {
window.parent.cqPackageShareClient.onStatus(pid, stat, p, max, msg);
window.scrollTo(0, 1000000);
}
</script></head>
<body><h2>Dump package contents</h2><div><span class="-"><b>-</b>&nbsp;META-INF/</span><br>
<script>
window.scrollTo(0, 1000000);
</script>
<span class="-"><b>-</b>&nbsp;META-INF/vault/</span><br>
<span class="-"><b>-</b>&nbsp;META-INF/vault/config.xml</span><br>
<span class="-"><b>-</b>&nbsp;META-INF/vault/filter.xml</span><br>
<span class="-"><b>-</b>&nbsp;jcr_root/.content.xml</span><br>
<span class="-"><b>-</b>&nbsp;META-INF/vault/nodetypes.cnd</span><br>
<span class="-"><b>-</b>&nbsp;META-INF/vault/properties.xml</span><br>
<span class="-"><b>-</b>&nbsp;META-INF/vault/definition/</span><br>
<span class="-"><b>-</b>&nbsp;META-INF/vault/definition/.content.xml</span><br>
</div><br>Contents dumped. in 1ms.<br><script type="text/javascript">
window.scrollTo(0, 1000000);
</script>
</body></html>

Building packages

To build a package, use the following command in your terminal:

curl -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/mycontent.zip?cmd=build

For example:

curl -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/my_packages/sarah.zip?cmd=build
{"success":true,"msg":"Package created"}

Rewrapping packages

To rewrap a package, use the following command in your terminal:

curl -u <uid>:<pwd> -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/mycontent.zip?cmd=rewrap

For example:

curl -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/my_packages/testpackage.zip?cmd=rewrap
{"success":true,"msg":"Definition repackaged"}

Installing packages

To install a package, use the following command in your terminal:

curl -u <uid>:<pwd> -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/mycontent.zip?cmd=install

Parameter Description
autosave Number of nodes after which to perform intermediate saves (optional)
recursive Set to true to install subpackages as well (optional)
acHandling Handling of the access control nodes contained in the package (optional):
  • ignore - Ignores the packaged access control and leaves the target unchanged.
  • overwrite - Applies the access control provided with the package to the target. This also removes the existing access controls.
  • clear - Clears all access control on the target system.

For example:

curl -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/my_packages/testpackage.zip?cmd=install
{"success":true,"msg":"Package installed"}

Uninstalling packages

To uninstall a package, use the following command in your terminal:

curl -u <uid>:<pwd> -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/mycontent.zip?cmd=uninstall

For example:

curl -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/my_packages/testpackage.zip?cmd=uninstall
{"success":true,"msg":"Package uninstalled"}

Uninstalling packages

To uninstall a package, use the following command in your terminal:

curl -u <uid>:<pwd> -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/mycontent.zip?cmd=uninstall

For example:

curl -X POST http://localhost:7402/crx/packmgr/service/.json/etc/packages/my_packages/testpackage.zip?cmd=uninstall
{"success":true,"msg":"Package uninstalled"}

Downloading Packages

Downloading support is provided through the normal Sling WebDav support. To download a package, you specify the path of the package in the repository, for example:

Path: /etc/packages/mypackage.zip

URL: http://localhost:4502/etc/packages/mypackage.zip

Command: curl -u <uid>:<pwd> http://localhost:4502/etc/packages/mypackage.zip

curl -u admin:admin http://localhost:4502/etc/packages/mypackage.zip

Using Package Share

The Package Share is a publicly available server to share Content-Packages, powered by Day. Packages can include official hotfixes, feature sets, and CQ/CRX-updates or CQ/CRX-user generated content to share with other users. Access to the Package Share is available for partners and customers of Day. A registration form in the Package Share must be filled out for access.

With Package Share, you can download Day content packages and also upload and share packages within your company.

Note

Package Share is currently unavailable if your company runs an http proxy that requires authentication. Package Share is only available when the machine where CRX is installed has access to the Internet without requiring authentication.

Note

You may experience problems when trying to access Package Share from a pure IPv6 environment.

This is because package share is service hosted on a server, meaning your connection is made through various networks on the internet. It cannot be ensured that all the connecting networks support IPv6; if not the connection might fail.

To avoid this issue, you can access Package Share from an IPv4 network, download the package and then upload it to the IPv6 environment.

Package Share Access and Structure

There is no anonymous access to the Package Share; that is, only registered users are allowed to view and download packages.

Note

To use Package Share functionality, you must have the appropriate access. For this you need to have an Adobe ID, with your email address as user identifier.

If you do not have an Adobe ID you will need to register. The registration page is available via a link on the Package Share sign in page.

The first time that you access Package Share with your Adobe ID you will be sent an email containing a link; clicking this link will provide the email validation that is required before sign in continues.

In the case that you have forgotten your password, there is another link on the Package Share sign in page that will take you to the Help pages.

The following describes the Package Share structure.

Note

Which packages are visible to you is determined by the license type of your CRX server and the company group you belong to.

Groups

The following groups are available for package share:

  • Company-internal sharing
  • Packages provided by Day (updates, feature packs, and hotfixes)
Public share

The package share group gives overall read permission to the package share and the public folder.  Individual company homes are denied. This folder is called Public and provides access to Day's public packages. 

Company share

Each company gets its own group with an allow read/write on its company home. In the example, Day is the user's company, which is why the user has access to those private packages.

Note

CRX Developer Edition users all have one "company share." All the packages uploaded to this area are visible to other users of the free CRX edition.

Users

A packageshare user is a member of his or her respective company group. A user of a partner can be a member of his or her customer groups.

Requesting access to the Package Share library

If you need access to Day's Package Share, please fill out the registration form.

Day will check with the appropriate departments for required/allowed permissions and add you to your company's group.

Package Status

In Day's Package Share library, each package has a status indicator to let you know whether you have already downloaded or installed the package. The indicator appears to the right of the package name as in the following example:

file
Package Status Description
Download This package is available for download. It has not been downloaded to your local CRX installation.
Downloaded This package has already been downloaded to your local CRX installation but has not yet been installed.
Installed This package has been downloaded and installed onto your local CRX installation.

Downloading and installing packages from Package Share

Before downloading and installing packages from Day's Package Share, be sure you have access to the library. See Requesting access to the Package Share library.

Caution

Installing a package can overwrite existing content in the repository. Therefore, Day recommends that you perform a Test Install first. With a test install, you can inspect whether the content that the package contains conflicts with your existing content.

To download and install packages from Package Share:

1. On the CRX main page, click Share. The Package Share page opens.

2. Log into Package Share. A list of folders and packages displays. You see a Public folder and one specific to your company.

3. Navigate to the package you want to download and click Download.

file

4. Once downloaded, the word Downloaded appears next to the package.

5. Navigate back to Packages and then navigate to the package you just downloaded.

Note

You find the package you just downloaded located at the same path as it appeared online. For example, if you downloaded a package from Packages > Public > CRX2.1 Hotfixes, your package appears at Packages > Public > CRX2.1 Hotfixes on your local CQ installation.

6. Click Install to install the package to your local CRX installation.

file

Note

If a package has already been installed on your installation, the word Share appears next to the package in the Package Manager.

file

Uploading packages to the company-internal Package Share

With Day's Package Share, you can upload and share packages within your company. These packages are not available to the general CRX community, but are available to all users registered with your company.

Note

After your packages are uploaded, you may be able to share them with the general CRX community. See making packages available to the CRX general public.

To upload packages to the company-internal Package Share:

  1. In CRX, open the Package Manager by clicking Packages.

  2. Navigate to the package you want to upload. Click the icon or the name of the package you want to uninstall to expand it.

    Note

    To share a package, ensure that you have put it in a folder named after your company, for example, geometrixx. Packages in the general Package Manager list or in other folders cannot be shared.

  3. Click Share to upload the package to Package Share. The Package Share asks you to log in if you have not already.

    Note

    The Package Share login is the same as your Adobe ID.

  4. In the Share Package window, click Share to upload it to your internal company's Package Share. CRX shows you the status and indicates when the package has finished uploading. After uploading, you can click the x from the window to exit the Share Package window.

    file

    After upload, navigate to your company's internal folder to see the package you just shared.

Making packages available to the Public Package Share

To make a package available to the general CRX/CQ community in the public Package Share:

  1. Upload your package to your company's internal Package Share site as described in Uploading packages to the company-internal Package Share.
  2. After it is uploaded, click Sign Up in the Public Sharing area of the page. Someone from Day will evaluate the package and post it to the public folder, if appropriate.

Content Loader

file
The Content Loader allows you to add content to the CRX repository. You can also transform XML data into a node structure in the CRX repository. This allows you to access all the nodes and properties of the XML file seamlessly from within CRX.
Root path for import The target path in the repository where the file is uploaded.
File to upload The file you want to upload. Currently, you can upload XML or ZIP files.
Auto-Expand Check to expand XML and ZIP archive files into a node structure of the CRX repository. Clear to save as one solid file.
Expand file content directly below selected root. Check to import the content directly into the repository structure. Clear to create an nt:file node that contains the imported content.
UUID behavior list If you import a package that contains repository data, select how CRX handles UUIDs during import:
  • Create new uuid: The imported nodes receive new UUIDs, which do not collide with existing UUIDs in the repository.
  • Remove existing uuid: If an imported node has the same UUID as an existing node, the existing node and its child nodes are removed.
  • Replace existing uuid: If an imported node has the same UUID as an existing node, the imported node replaces the existing node.
  • Throw exception: CRX refuses to import the node and throws an exception.
Intermediate save calls When you import a ZIP archive file, CRX saves after importing each file in the archive. This allows you to import large archive files.
Add version support Adds the node type “mix:versionable”, so the imported content is versionable.
Check in If set, the imported content is checked in. If cleared, the content is checked out, so you can edit it, and later check it in.
Import Imports the data with the settings you have made above.

Content Zipper

file
The Content Zipper allows you to export part of the repository.
Root path for export Click Browse to select a node. The node and all nodes below it are exported.
Format The target format
CRX Package: Stores the same information as the system view, but uses Day's proprietary CRX package format. This format is faster and smaller, but you can use it only with CRX.
XML Doc View: A document view of the repository. This view is optimized for clarity and simplicity, but may not support some advanced repository features.
XML Sys View: A system view of the repository. This view perfectly mirrors the state of the repository, but the resulting XML code can become fairly complex.
ZIP file: Stores files and folders in a compressed form. All nodes must have the node type nt:file or nt:folder.
Export Exports the selected part of the repository in the specified format.