[
https://issues.apache.org/jira/browse/JCRVLT-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17139185#comment-17139185
]
Dominik Süß commented on JCRVLT-443:
------------------------------------
We do have some checks for the sling feature launcher - that is IMHO sufficient
for vault. We "may" consider to have optional validator plugins (some SPI) to
be able to validate dependencies of nested content in the vault plugin, but at
least right now this is covered downstream. The question if we want to expand
the requirements & capability validation part (similar to osgi, or potentially
providing a hook to make packages be able to hook into the osgi resolution
process) is apart from the fact that dependencies of containers that don't
really provide own direct data are an additional source of error that don't
provide additional value against cleanly describing the dependencies on the
nested items that hold the content (depending on other packages that directly
hold the corresponding content they depend on).
It sure often is easier to just define dependencies on a coarse grained level
but as [~tripod] indicated we had to learn the hard way that id changes of
containers (hotfix vs service pack vs feature pack etc) can easily cause the
dependencies to no longer be correct. Containers should only be shipping units
while only the actual installables have meaningful ids and versions to be
evaluated.
> Allow dependencies in "container" package type
> ----------------------------------------------
>
> Key: JCRVLT-443
> URL: https://issues.apache.org/jira/browse/JCRVLT-443
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
> Affects Versions: 3.4.4
> Reporter: Konrad Windszus
> Priority: Major
> Fix For: 3.4.6
>
>
> According to JCRVLT-170 {{container}} packages must not have package
> dependencies.
> Sometimes there are multiple container packages though and with the nesting
> of container packages added in JCRVLT-401 it makes sense now to add package
> dependencies also to containers (to enforce a certain order in case they are
> nested or just because at build time the dependency cannot be resolved, i.e.
> included in the container package)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
