[JCRVLT-170] Introduce the concept of package types

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 3.1.42
• Component/s: Packaging
• Assignee: Tobias Bocanegra
• Reporter: Tobias Bocanegra
• Created: 07/Apr/17 12:07
• Updated: 26/Jan/21 13:14
• Resolved: 30/Oct/17 07:12

Description

Overview

content packages can be used for various purposes and this should be reflected by package types. the types distinguish primarily between packages with code and packages with content. other types are container packages that only contain sub-packages.

Application Packages

For code deployment scenarios the simplicity of filter roots and the accuracy of dependencies is more important than for normal content packages.

The application packages have the characteristic that:

• they only provide content to /apps, /libs (thus are instance private)
• they only contain disjunct subtrees (i.e. not include/exclude in the filter patterns)
• don't create snapshots when installed, i.e. uninstalling them means deleting the content below the subtree and installing the previous version
• don't include sub-packages
• don't include OSGi configuration or bundles
• define proper dependencies to other application packages (i.e. all ancestor paths of their import filters must be covered by one dependent package)
• do not include oak index definitions
• do not include hooks

Content Packages

The content packages contain content and user configuration

• don't have content below /apps or /libs
• don't include OSGi configuration or bundles
• can have sub-packages to other content packages (but not to app packages)

Container Packages

As for the container / deployment packages they have the characteristics that:

• they don't contain any content
• they contain a set of application content packages
• they don't have dependencies on other deployment packages (i.e. the dependencies are implicit given by the relations of the included artifacts)

It is to discuss if the container packages should be allowed to carry bundles and config. maybe they should be handled completely different, such as using sling provisioning.

Mixed Package

This is the catch-all case of the above for legacy content. Ideally we don't have any of those on the long run.

Issue Links

• causes: JCRVLT-403 Clarify usage of package type "application" for overlays
• causes: JCRVLT-443 Allow dependencies in "container" package type
• causes: JCRVLT-401 Clarify allowed contents of container package type
• is related to: JCRVLT-496 Clarify usage of oak:index in application packages
• is related to: JCRVLT-232 Enforce constraints for package types
• is related to: JCRVLT-493 Document restrictions of package types
• relates to: JCRVLT-220 Include package type when assembling a package