[
https://issues.apache.org/jira/browse/JCRVLT-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17017019#comment-17017019
]
Dominik Süß commented on JCRVLT-170:
------------------------------------
[~kwin] the idea behind that was that application packages must have all their
parent dependencies (structural) defined and analysers can look up and validate
those by checking the referenced artifacts thought their maven dependency. Each
node "should" have a single source of truth - merging scenarios optimally are
only necessary for ac merge. If a repository structure package is being used
the one maintaining the structure package must make sure that this really is
the correct information and the system really will establish what the structure
package declares.
Still I see some cases where one might want to use includes and excludes - to
reduce the amount of filters to add a bigger amount of subnodes in a node that
is owned by another package - yet it is something slightly ambiguous to define
as the filter itself would need to exclude the parent node to not collide with
the package owning it. In the past that led to quite some ambiguity where
multiple packages defined the same node and eventually just the order defined
which of the definitions got finally applied.
> 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)
