Fork me on GitHub

Package Types


Package types limit what repository locations a content package may contain (JCRVLT-170). In addition they may impose other limitations in terms of install hooks, package dependencies and allowed filter rules. The package type classification helps to clarify the purpose and also eases the deployment of the package (e.g. when using the Oak Composite Node Store, which mounts several repository folders in read-only mode). The package type is set in the package properties.

Package types are not evaluated in any way (yet) when importing packages. Currently their restrictions are only enforced by the jackrabbit-packagetype validator and to a certain degree evaluated by third party tools like Apache Sling Content-Package to Feature Model Converter.


Package Type Allowed repository locations Allows OSGi bundles/configurations/sub packages Allows package dependencies Allows install hooks
Application /apps, /libs no yes no
Content everything except /apps, /libs partially (only content sub packages) yes yes
Container no regular content yes no yes
Mixed all yes yes yes

Application Package

This package type is supposed to be used for everything which makes up the “code” part of the application which is used directly from the repository, i.e. (non-bundled) scripts, resource types, … To ease combination of multiple application packages they should contain only disjunct sub trees (i.e. no include/exclude filter patterns). As this cannot always be achieved in reality this rule can be relaxed with the validator setting allowComplexFilterRulesInApplicationPackages. In addition they must not contain install hooks.

Content Package

This package must not contain any nodes below /apps or /libs. Sub packages of type content are allowed (but only below /etc/packages). All other sub package types are not valid in this type.

Container Package

Container packages act as deployment vehicle and don't contain regular nodes. Only OSGi bundles, configuration and sub packages (for use with the OSGi Installer) are allowed. In addition also sub packages below /etc/packages/... are supported.

Containers may be nested which means they may contain itself packages of type container.

Mixed Package

This legacy package type imposes no restrictions and is only defined for backwards-compatibility reasons. For new packages rather one of the other types should be used as mixed packages may not deployable in certain scenarios.