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
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!
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: