Defines whether the package is allowed to contain index definitions. This will become the allowIndexDefinitions property of the properties.xml file.

The archive configuration to use. See the documentation for Maven Archiver. All settings related to manifest are not relevant as this gets overwritten by the manifest in AbstractPackageMojo.workDirectory

The directory containing the content to be packaged up into the content package. This property is deprecated; use jcrRootSourceDirectory instead.

The file name patterns to exclude in addition to the ones listed in AbstractScanner.DEFAULTEXCLUDES. The format of each pattern is described in DirectoryScanner. The comparison is against the path relative to the according filter root. Since this is hardly predictable it is recommended to use only filename/directory name patterns here but not take into account file system hierarchies!

Each value is either a regex pattern if enclosed within %regex[ and ], otherwise an Ant pattern.

Set to false to not fail the build in case of files/folders being added to the resulting package more than once. Usually this indicates overlapping with embedded files or overlapping filter rules.

Set to true to fail the build in case of files are being contained in the jcrRootSourceDirectory which are not covered by the filter rules and therefore would not end up in the package.

The name of the generated package ZIP file without the ".zip" file extension.

The directory that contains the jcr_root of the content. Multiple directories can be specified as a comma separated list, which will act as a search path and cause the plugin to look for the first existing directory.

The directory that contains the META-INF/vault. Multiple directories can be specified as a comma separated list, which will act as a search path and cause the plugin to look for the first existing directory.

This directory is added as fileset to the package archiver before the the workDirectory. This means that files specified in this directory have precedence over the one present in the workDirectory. For example, if this directory contains a properties.xml it will not be overwritten by the generated one. A special case is the filter.xml which will be merged with inline filters if present.

Directory in which the built content package will be output.

Defines the content package type. this is either 'application', 'content', 'container' or 'mixed'. If omitted, it is calculated automatically based on filter definitions. certain package types imply restrictions, for example, 'application' and 'content' packages are not allowed to contain sub packages or embedded bundles.
Possible values:

• application: An application package consists purely of application content. It serializes entire subtrees with no inclusion or exclusion filters. it does not contain any subpackages nor OSGi configuration or bundles.
• content: A content package consists only of content and user defined configuration. It usually serializes entire subtrees but can contain inclusion or exclusion filters. it does not contain any subpackages nor OSGi configuration or bundles.
• container: A container package only contains sub packages and OSGi configuration and bundles. The container package is only used as container for deployment.
• mixed: Catch all type for a combination of the above.

Adds a path prefix to all resources useful for shallower source trees. This does not apply to files in workDirectory.

The directory containing the metadata to be packaged up into the content package. Basically containing all files/folders being generated by goal "generate-metadata".