[
https://issues.apache.org/jira/browse/JCRVLT-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142144#comment-17142144
]
Dominik Süß commented on JCRVLT-443:
------------------------------------
[~kwin] - in this case you need to provide a validator that can evaluate the
java exports. That's where I suggest an SPI that allows adding a custom
validator that depending on the runtime can evaluate which packages would be
exposed to scripts of the package, otherwise you will never be able to evaluate
if import-packages is being satisfied.
And still - container packages shouldn't have impact on installation order as
changes in how to aggregate into containers might happen without any change of
the actual content. So if packages a,b,c & d contain content the dependencies
between those should define the installation order, a wrapping container should
never have impact - it should not be abused to "fix" missing dependencies
between packages as the complexity to manage such transient dependencies can
quite easily get overwhelming and unmanagable and lock you in certain shipping
structures.
> 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)
