[ 
https://issues.apache.org/jira/browse/JCRVLT-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17016199#comment-17016199
 ] 

Konrad Windszus edited comment on JCRVLT-170 at 1/15/20 6:25 PM:
-----------------------------------------------------------------

[~dsuess][~tripod] Another question about the limitation of not using 
includes/excludes with package type {{application}}. How do you correctly 
package overlay packages then with regards to ancestor nodes? Imagine I have 
one apps package with overlay {{/apps/cq/core/content/nav/tools/security/foo}} 
and another one with {{/apps/cq/core/content/nav/tools/security/bar}}. How do I 
ensure that the ancestor nodes have the right node types (i.e. which package 
should cover the ancestor nodes {{/apps/cq/core/content/nav/tools/security}} up 
to {{/apps}}?


was (Author: kwin):
[~dsuess][~tripod] Another question about the limitation of not using 
includes/excludes with package type `application`. How do you correctly package 
overlay packages then with regards to ancestor nodes? Imagine I have one apps 
package with overlay `/apps/cq/core/content/nav/tools/security/foo` and another 
one with `/apps/cq/core/content/nav/tools/security/foo`. How do I ensure that 
the ancestor nodes have the right node types (i.e. which package should cover 
the ancestor node `/apps/cq/core/content/nav/tools/security` up to `/apps`, 
which is a known/existing root).

> 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
>            Priority: Major
>             Fix For: 3.1.42
>
>
> 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
(v8.3.4#803005)

Reply via email to