Uploaded image for project: 'Jackrabbit FileVault'
  1. Jackrabbit FileVault
  2. JCRVLT-170

Introduce the concept of package types

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.1.42
    • Component/s: Packaging
    • Labels:
      None

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                tripod Tobias Bocanegra
                Reporter:
                tripod Tobias Bocanegra
              • Votes:
                1 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: