[
https://issues.apache.org/jira/browse/JCRVLT-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated JCRVLT-170:
------------------------------------
Description:
h1. 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.
h2. 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
h2. 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)
h2. 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.
h2. 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.
was:
For code deployment scenarios the simplicity of filter roots and the accuracy
of dependencies is more important than for normal content packages.
also the mixture of content/code and ACL might be problematic.
for application packages the following rules should apply:
- they expose a specific manifest header: {{Content-Package-Type: application}}
- the workspace filter must not contain regexps and no import modes
- it should not contain content (i.e. nodes outside /apps, /libs, ...)
- it should not mix code and ACLs
- it must define dependencies to packages that define the parent nodes of all
filters
- (other type of packages are {{content}}, {{mixed}}, {{container}}
> Introduce the concept of package types
> --------------------------------------
>
> Key: JCRVLT-170
> URL: https://issues.apache.org/jira/browse/JCRVLT-170
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
> Reporter: Tobias Bocanegra
> Assignee: Tobias Bocanegra
>
> h1. 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.
> h2. 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
> h2. 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)
> h2. 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.
> h2. 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.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
