Uploading a package from a maven repository

The only convenience goal provided by the vltpack-maven-plugin for general package installation is the upload-from-repo goal. This goal is intended to be executed outside of a maven project, and requires the user to specify a coords property that defines a set of maven artifact coordinates in compact, colon-delimited form. The value of this property will be resolved against your local and active remote repositories. If an artifact is resolved and the artifact file is a valid CRX package, the file will be uploaded and installed. For example, this command will upload and install Recap from the Maven Central repository:

mvn net.adamcin:vltpack-maven-plugin:1.0.0:upload-from-repo -Dcoords=net.adamcin.recap:recap-graniteui:zip:0.8.0

Uploading a vltpack project artifact as part of a maven build

The vltpack-maven-plugin will upload and install the main project artifact to the configured CQ server during a maven build if the supportITs property is set to true. This can also be specified in a user profile to make CQ installation of the package easier in IDEs, but wouldn't you rather be uploading JSPs and content with the vlt tool instead? Just think of the size of your CRX DataStore!

Common HTTP Parameters

The vltpack-maven-plugin was designed to allow the use of profiles defined in a user's settings.xml to target commonly-used CRX servers for package upload, bundle installation, and integration test execution. By default, the plugin attempt to connect to a CRX server at http://localhost:4502/crx with basic credentials of admin:admin. To target a different port, one can simply create a profile in ~/.m2/settings.xml that sets the vltpack.port property, and activate it. For example, to easily target a publish server running locally on the conventional port 4503, add the following profile:

<profile>
    <id>publish-server</id>
    <properties>
        <vltpack.port>4503</vltpack.port>
    </properties>
</profile>
                

Setting a single property is of course, not very impressive, but imagine that you must upload to a shared CQ integration server running on a non-standard port with admin credentials disabled, which also happens to be sitting behind its own HTTP proxy and is mapped to a different context path in order to integrate with a corporate SSO configuration. Suddenly a user profile starts to look more attractive, yes?

<profile>
    <id>corp-CQ-IT-auth-server</id>
    <properties>
        <vltpack.host>cqhqdevauth01</vltpack.host>
        <vltpack.port>8502</vltpack.port>
        <vltpack.user>jenkins</vltpack.user>
        <vltpack.pass>Chang3m3</vltpack.pass>
        <vltpack.context>/cq</vltpack.context>
        <vltpack.proxy.set>true</vltpack.proxy.set>
        <vltpack.proxy.host>dmzNA083.corp.acme.com</vltpack.proxy.host>
        <vltpack.proxy.user>appuser0159</vltpack.proxy.user>
        <vltpack.proxy.pass>October19</vltpack.proxy.pass>
    </properties>
</profile>
                

In addition to HTTP parameters, goals which upload and install packages also accept the following user properties to control the behavior of the package installation process:

vltpack.upload.force (default: false)

Set to true to upload and install the package even if a package with the same ID (group:name:version) is already installed on the server.

vltpack.upload.recursive (default: true)

Set to false to disable recursive installation of subpackages.

vltpack.upload.autosave (minimum: 1024)

Increase this value in order to optimize the performance of package installation, based on the characteristics of the target server (significant concurrent activity, clustered repository, large number of affected nodes, etc.).

vltpack.upload.timeout (default: 60)

Set the number of seconds to wait for CRX Package Manager service availability before failing the execution. The vltpack-maven-plugin checks for service availability before each POST request in order to avoid a minor yet annoying behavior caused such requests if they are sent to the Package Manager service URL while the bundle is temporarily deactivated, which can happen immediately after installing another package with embedded OSGi bundles. The SlingPostServlet ends up handling the request, which creates nodes in the repository at /crx/packmgr/*. The existence of these nodes confuses the CQ Link Rewriter Filter, which then decides to change the Package Manager link on the CQ Welcome page from /crx/packmgr/ to /crx/packmgr.html, which is incorrect. If you ever see this happen on one of your servers, it is probably caused by this issue.