Usage¶

Overview¶

The Build Tools for VMware Aria ecosystem consists of archetypes, Maven goals, and helper tools that cover every product combination. This page keeps the most common operations, product-specific notes, packaging options, licensing helpers, and IDE guidance in one place.

Operational quick reference¶

Command cheat sheet¶

mvn clean package
mvn clean package -Pbundle-with-installer
mvn clean package vrealize:push -P{profile}
mvn vrealize:clean -DincludeDependencies=true -DcleanUpOldVersions=true -DcleanUpLastVersion=false -Ddryrun=true -P{profile}

Common build flags & troubleshooting¶

-DincludeDependencies=false keeps the push focused on your artifacts, while -Dfiles=Name1,Name2 pinpoints only the modified JS/TS dependencies.
Add -Dvrealize.ssl.ignore.certificate and/or -Dvrealize.ssl.ignore.hostname only in labs; the General archetype docs emphasize keeping TLS checks enabled in prod.
Troubleshooting tips: re-run failing commands with -X for debug output or -U to force fresh dependencies when Maven caches drift.

Caution

Clean/push/pull honor the -P{profile} you pass. Keep secrets encrypted (use settings-security.xml + encrypted servers) when operating from CI.

`vrealize:clean` support matrix¶

vrealize:clean is available for the archetypes that target remote package cleanup. The general documentation highlights what is supported today:

Archetype	Support	Notes
`vra`	Yes	Full support across environments.
`vro`	Yes	Works for all Orchestrator packages.
`vcd`	Partial	Supports everything except dry run.
`abx`	No	Not implemented.
`vrops`	No	Not implemented.
`vra-ng`	Partial	No dry run; regional content is excluded.
`vrli`	No	VRLI lacks native package APIs.
`cs`	No	Code Stream Services does not expose packages.

Use mvn vrealize:clean -DincludeDependencies=true -DcleanUpOldVersions=true -DcleanUpLastVersion=false -Ddryrun=true -P{profile} to align with the documented defaults.

Product pathways¶

Orchestrator (JS/XML/TS)vRA 8 / VCF AutomationAria Operations & VCF OperationsOperations for LogsPolyglot / ABX

Summary¶

Project type	Archetype	Supported content
TypeScript vRO	`package-typescript-archetype`	Actions, workflows, policy templates, configuration elements, resource elements, native content, and type definitions.
JS/XML vRO	Product-specific vRO archetypes in the same family	Same vRO packaging and push model through `vrealize:push`.

Structure¶

TypeScript projects generated by the archetype include: - Root files: pom.xml, release.sh, tsconfig.json. - src/<module>/actions/*.ts|*.js - src/<module>/workflows/*.wf.ts (+ optional *.wf.form.json) - src/<module>/policies/*.pl.ts - src/<module>/*.conf.ts|*.conf.yaml for configuration elements - src/<module>/resources/* and src/<module>/types/*.d.ts - Unit tests: *.test.ts, *.spec.ts, and JS tests under src/test for action-based projects.

Profile parameters (`~/.m2/settings.xml`)¶

Core Orchestrator profile keys: - vro.host, vro.port - vro.auth (basic or vra) - vro.authHost, vro.authPort (required for external auth flows) - vro.username, vro.password

For VCF 9 Orchestrator, username format is user@domain (for example admin@System or configurationadmin@Classic).

Operations and behavior¶

Push: mvn clean package vrealize:push -P{profile}
Pull: mvn vro:pull -P{profile} (optionally -DpackageName=...)
Actions pushed only from src and only when extension is .js or .ts.
Action names are restricted to ^[a-zA-Z0-9_$]+$ and cannot end with helper suffixes (.helper.ts, .helper.js, _helper.js).
Config values require explicit flags: -Dvro.packageImportConfigurationAttributeValues=true and -Dvro.packageImportConfigSecureStringAttributeValues=true.
Node dependency reinstall can be skipped with -DskipInstallNodeDeps=true.

`.vroignore`¶

The default .vroignore controls packaging, compilation, testing, and helper-file behavior. Override its name with vroIgnoreFile if needed.

General¶

This file contains glob patterns for file paths to be ignored during compilation, packaging and testing.¶

The file will be (re)generated when the project is rebuilt to maintain the default categories and patterns, ignoring blank lines and repeating comments.¶

The default categories, defined as rows starting with a single '#', are 'General', 'Packaging', 'Compilation', 'Testing', 'TestHelpers'.¶

Patterns not under one of those categories will be considered in the 'General' category and ignored during all operations.¶

Patterns must be listed on separate rows (without in-line comments), can be negated with a single '!' at the start and will be trimmed before processing.¶

The 'TestHelpers'category will contain these two patterns by default: '**/*_helper.js', '**/*.helper.[tj]s'¶

Rows starting with '##' are considered as comments and will be ignored on processing.¶

Packaging¶

Files with these paths will not be included in the vro package.¶

For Workflows, Configurations, Resources and Policies: it is recommended to use the 'General' category (will skip xml element generation).¶

Otherwise the patterns below must be based on the element name.element_info.xml files in target/vro-sources/xml.¶

Compilation¶

Files with these paths will be compiled without TS definitions¶

Testing¶

Files with these paths will be excluded from test coverage¶

TestHelpers¶

Files with these paths will be included in the tests but will not have TS definitions and will not be included in the test coverage or the vro package¶

/*_helper.js /*.helper.[tj]s

Summary¶

Field	Value
Archetype	`package-vra-ng-archetype`
Product compatibility	`vRA 8` and VCF Automation Classic
Model	Descriptor-driven pull (`content.yaml`) + source content under `src/main`

Structure¶

catalog
├── README.md
├── content.yaml
├── pom.xml
├── release.sh
└── src
    └── main
        └── blueprints
            └── blueprint.yaml
            └── content.yaml
            └── versions.yaml
        └── content-sources
            └── source.json
        └── property-group
            └── property_group_name.json
        └── catalog-items
            └── forms
                └── source name__workflow one name with custom form.json
                └── source name__workflow one name with custom form__FormData.json
                └── source name__workflow three name with custom icon and form.json
                └── source name__workflow three name with custom icon and form__FormData.json
            └── icons
                └── source name__workflow two name with custom icon.png
                └── source name__workflow three name with custom icon and form.png
            └── source name__workflow one name with custom form.json
            └── source name__workflow two name with custom icon.json
            └── source name__workflow three name with custom icon and form.json
        └── entitlements
            └── Blueprint.yaml
            └── Workflow.yaml
            └── ABX Action.yaml       
        └── subscriptions
            └── subscription.json
        └── custom-resources
            └── customResource.json
        └── resource-actions
            └── resourceAction.json
        └── policy
            └── approval
                └── aprovalPolicy1.json
            └── content-sharing
                └── contentSharingPolicy1.json
            └── day2-actions
                └── day2ActionsPolicy1.json
            └── deployment-limit
                └── deploymentLimitPolicy1.json
            └── lease
                └── leasePolicy1.json 
            └── resource-quota
                └── resourceQuotaPolicy1.json 
        └── scenarios
            └── Scenario Name.json

Supported content (`content.yaml`)¶

blueprint
subscription
custom-resource
resource-action
catalog-entitlement
catalog-item
content-source
property-group
scenario
policy (approval, content-sharing, day2-actions, deployment-limit, lease, resource-quota)

Profile parameters (`~/.m2/settings.xml`)¶

Base connectivity: - vrang.host, vrang.port, vrang.csp.host, vrang.proxy - vrang.username, vrang.password, vrang.refresh.token - vrang.tenant, vrang.org.name, vrang.project.name Import tuning: - vrang.bp.unrelease.versions - vrang.vro.integration - vrang.import.timeout - vrang.data.collection.delay.seconds

Operations and behavior¶

Pull: mvn vra-ng:pull -P{profile} uses content.yaml filters.
Push: mvn clean package vrealize:push -P{profile} always pushes all local content from src and does not filter by content.yaml.
Export rules: empty list exports none, explicit list exports those names, null exports all for supported types.

Note

Catalog entitlements were used in Aria Automation 8.0 to 8.8.1 and replaced by content-sharing policies in 8.8.2.

Summary¶

Field	Value
Archetype	`package-vrops-archetype`
Product compatibility	Aria Operations 8.x and VCF Operations 9.x
Model	Descriptor-driven pull/import with `content.yaml` and resources under `src/main/resources`

Structure¶

Root: content.yaml, pom.xml, release.sh
src/main/resources/views/, dashboards/, alert_definitions/, symptom_definitions/
policies/, recommendations/, supermetrics/, metricconfigs/, reports/, custom_groups/
Several resources include sidecar metadata and .properties files.

Supported content (`content.yaml`)¶

view
dashboard
alert-definition
symptom-definition
policy
default-policy (single value, not a list)
recommendation
super-metric
metric-config
report
custom-group

Profile parameters (`~/.m2/settings.xml`)¶

Connectivity and auth: - vrops.host, vrops.port, vrops.sshPort - vrops.username, vrops.password - vrops.restUser, vrops.restPassword - vrops.restAuthSource, vrops.restAuthProvider (BASIC or AUTH_N) Dashboard ownership: - vrops.dashboardUser - vrops.importDashboardsForAllUsers

Operations and behavior¶

Pull: mvn vrops:pull -P{profile}
Push: mvn clean package vrops:push -P{profile}
Import/export are explicit-list based. default-policy is not exported and only sets an existing policy during import.
Wildcards are supported for most assets; not supported for dashboards and metric-configs.

Summary¶

Field	Value
Archetype	`package-vrli-archetype`
Product compatibility	vRLI / Aria Operations for Logs 8.x / VCF Operations for Logs 9.x
Model	Descriptor-driven pull + local resources under `src/main/resources`

Structure¶

Root: content.yaml, pom.xml, release.sh
src/main/resources/alerts/
src/main/resources/content-packs/

Supported content (`content.yaml`)¶

alerts
content-packs

Profile parameters (`~/.m2/settings.xml`)¶

Base connectivity: - vrli.host, vrli.port - vrli.username, vrli.password - vrli.provider (Local, active directory, VIDM) Optional vROps-backed alert integration: - vrli.vropsHost, vrli.vropsPort, vrli.vropsUser, vrli.vropsPassword, vrli.vropsAuthSource

Operations and behavior¶

Pull: mvn vrli:pull -P{profile}
Push: mvn clean package vrealize:push -P{profile}
Import behavior pushes all local objects in src.
Export behavior only pulls explicitly listed items from content.yaml.
Wildcards are supported during pull filtering.

Summary¶

Type parameter	Target	Runtime set
`-Dtype=vro`	Orchestrator Polyglot Actions	`node:12\|14\|18\|20\|22`, `powercli:*`, `powershell:7.4`, `python:3.7\|3.10`
`-Dtype=abx`	ABX Actions	`nodejs`, `powershell`, `python`

Structure¶

Generated project is centered on src action folders.
Each action folder contains polyglot.json plus runtime-specific handlers (handler.ts, handler.py, handler.ps1).
Template folders (template-nodejs, template-powershell, template-python) are ignored when packaging.
polyglot.json controls:
platform.action, platform.entrypoint, platform.runtime, platform.timeoutSec, platform.memoryLimitMb
optional platform.environment (vRO custom environment)
optional platform.protocolType (Ssl3, Tls, Tls11, Tls12, Tls13)
vro.inputs/vro.outputType or abx.inputs, depending on project type.

Operations and behavior¶

type=vro projects use Orchestrator profile keys (vro.*) like the Orchestrator tab above.
type=abx projects do not use vrang.* by default; configure the profile and packaging inputs required by your ABX target integration.
Push command: mvn clean package vrealize:push -P{profile}.

Multi-module & packaging¶

ts-vra-ng is tailored for combined TypeScript + vRA NG solutions (maven/archetypes/ts-vra-ng/create.sh).
The mixed archetype (maven/archetypes/mixed/create.sh) lets you graft in custom workflows, licenses, and workflow paths without rewriting every command.
The bsc-package-maven-plugin (see docs/versions/latest/General/Cheatsheets/bsc-plugin-arguments.md) packages arbitrary content into a ZIP that you can deploy via SSH. Configure vroIgnoreFile when you need a nonstandard ignore list (.vroignore is the default).

Bundling & distribution¶

Create installation-ready bundles with Maven and use the bundled CLI to push them to any target environment.

mvn clean package -Pbundle-with-installer
./bin/installer
./bin/installer ./bin/environment.properties

Repeatable deployments reuse the trimmed environment.properties sample shown on the Getting Started page, which contains just the SSL flags and the common vRO settings. The bundle installer will prompt for workflow inputs unless you keep vro_run_workflow=false in that file.

# Example properties file
ignore_ssl_certificate_verification=true
ignore_ssl_host_verification=true

vro_import_packages=true
vro_enable_backup=true
vro_server=vra-l-01a.corp.local
vro_port=443
vro_auth=basic
vro_tenant=vsphere.local
vro_username=administrator@vsphere.local
vro_password={ENCODED_PASSWORD_PLACEHOLDER}

vro_import_old_versions=true
vro_import_configuration_attribute_values=false
vro_import_configuration_secure_attribute_values=false
vro_delete_old_versions=true

# Skip workflow execution in shared environments
vro_run_workflow=false

Licensing plugin¶

Add licenseUrl, licenseHeader, or licenseTechnicalPreview when you generate a project to preseed the Maven license plugin.
Maven will populate license_data/licenses.properties and inject headers while running mvn install.
Generate third-party notices with mvn license:add-third-party -Dlicense.useMissingFile.

IDE & developer tools¶

The vRealize Developer Tools (vRDT) VS Code extension exposes environment profiles, IntelliSense for scriptable objects, Run Action / inventory views, and build tasks for push/pull operations (see docs/Using-the-VS-Code-Extension.md).
The vrdev.tasks.exclude setting lets you hide library projects from the task list when you only push a subset of artifacts.
Inventory caching is available but must be disabled or refreshed when you update packages on the server.

Note

The legacy transcript warns that the extension's vRealize: New Project command is limited to a handful of archetypes, so prefer mvn archetype:generate for full control (docs/ppt_transcript.md).

Usage¶

Overview¶

Operational quick reference¶

Command cheat sheet¶

Common build flags & troubleshooting¶

vrealize:clean support matrix¶

Product pathways¶

Summary¶

Structure¶

Profile parameters (~/.m2/settings.xml)¶

Operations and behavior¶

.vroignore¶

General¶

This file contains glob patterns for file paths to be ignored during compilation, packaging and testing.¶

The file will be (re)generated when the project is rebuilt to maintain the default categories and patterns, ignoring blank lines and repeating comments.¶

The default categories, defined as rows starting with a single '#', are 'General', 'Packaging', 'Compilation', 'Testing', 'TestHelpers'.¶

Patterns not under one of those categories will be considered in the 'General' category and ignored during all operations.¶

Patterns must be listed on separate rows (without in-line comments), can be negated with a single '!' at the start and will be trimmed before processing.¶

The 'TestHelpers'category will contain these two patterns by default: '/*_helper.js', '/*.helper.[tj]s'¶

Rows starting with '##' are considered as comments and will be ignored on processing.¶

Packaging¶

Files with these paths will not be included in the vro package.¶

For Workflows, Configurations, Resources and Policies: it is recommended to use the 'General' category (will skip xml element generation).¶

Otherwise the patterns below must be based on the element name.element_info.xml files in target/vro-sources/xml.¶

Compilation¶

Files with these paths will be compiled without TS definitions¶

Testing¶

Files with these paths will be excluded from test coverage¶

TestHelpers¶

Files with these paths will be included in the tests but will not have TS definitions and will not be included in the test coverage or the vro package¶

Summary¶

Structure¶

Supported content (content.yaml)¶

Profile parameters (~/.m2/settings.xml)¶

Operations and behavior¶

Summary¶

Structure¶

Supported content (content.yaml)¶

Profile parameters (~/.m2/settings.xml)¶

Operations and behavior¶

Summary¶

Structure¶

Supported content (content.yaml)¶

Profile parameters (~/.m2/settings.xml)¶

Operations and behavior¶

Summary¶

Structure¶

Operations and behavior¶

Multi-module & packaging¶

Bundling & distribution¶

Licensing plugin¶

IDE & developer tools¶

`vrealize:clean` support matrix¶

Profile parameters (`~/.m2/settings.xml`)¶

`.vroignore`¶

The 'TestHelpers'category will contain these two patterns by default: '**/*_helper.js', '**/*.helper.[tj]s'¶

Supported content (`content.yaml`)¶

Profile parameters (`~/.m2/settings.xml`)¶

Supported content (`content.yaml`)¶

Profile parameters (`~/.m2/settings.xml`)¶

Supported content (`content.yaml`)¶

Profile parameters (`~/.m2/settings.xml`)¶