[jira] [Updated] (JCRVLT-403) Clarify usage of package type "application" for overlays
[
https://issues.apache.org/jira/browse/JCRVLT-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-403:
---
Fix Version/s: (was: 3.4.12)
> Clarify usage of package type "application" for overlays
>
>
> Key: JCRVLT-403
> URL: https://issues.apache.org/jira/browse/JCRVLT-403
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> According to JCRVLT-170 it is not allowed to use {{includes}} or {{excludes}}
> below a filter rule for {{application}} packages. This is a pretty common
> pattern though for including overlays in an apps package to enforce creating
> the ancestor nodes with the right type.
> See also
> https://issues.apache.org/jira/browse/JCRVLT-170?focusedCommentId=17016199&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17016199
> The use case of two different apps packages providing overlays below the same
> ancestor node should be supported (with both apps packages not knowing
> anything about each other) and still ensuring that the right node type is
> being created for ancestors.
> There must be a way of enforcing a certain ancestor node type during import
> and creating it in case it is not yet there, and failing in case if the
> ancestor is there with a different/incompatible type.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JCRVLT-403) Clarify usage of package type "application" for overlays
[
https://issues.apache.org/jira/browse/JCRVLT-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-403:
---
Fix Version/s: (was: 3.4.10)
3.4.12
3.4.12
> Clarify usage of package type "application" for overlays
>
>
> Key: JCRVLT-403
> URL: https://issues.apache.org/jira/browse/JCRVLT-403
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.12
>
>
> According to JCRVLT-170 it is not allowed to use {{includes}} or {{excludes}}
> below a filter rule for {{application}} packages. This is a pretty common
> pattern though for including overlays in an apps package to enforce creating
> the ancestor nodes with the right type.
> See also
> https://issues.apache.org/jira/browse/JCRVLT-170?focusedCommentId=17016199&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17016199
> The use case of two different apps packages providing overlays below the same
> ancestor node should be supported (with both apps packages not knowing
> anything about each other) and still ensuring that the right node type is
> being created for ancestors.
> There must be a way of enforcing a certain ancestor node type during import
> and creating it in case it is not yet there, and failing in case if the
> ancestor is there with a different/incompatible type.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JCRVLT-403) Clarify usage of package type "application" for overlays
[
https://issues.apache.org/jira/browse/JCRVLT-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-403:
---
Fix Version/s: (was: 3.4.8)
3.4.10
> Clarify usage of package type "application" for overlays
>
>
> Key: JCRVLT-403
> URL: https://issues.apache.org/jira/browse/JCRVLT-403
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.10
>
>
> According to JCRVLT-170 it is not allowed to use {{includes}} or {{excludes}}
> below a filter rule for {{application}} packages. This is a pretty common
> pattern though for including overlays in an apps package to enforce creating
> the ancestor nodes with the right type.
> See also
> https://issues.apache.org/jira/browse/JCRVLT-170?focusedCommentId=17016199&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17016199
> The use case of two different apps packages providing overlays below the same
> ancestor node should be supported (with both apps packages not knowing
> anything about each other) and still ensuring that the right node type is
> being created for ancestors.
> There must be a way of enforcing a certain ancestor node type during import
> and creating it in case it is not yet there, and failing in case if the
> ancestor is there with a different/incompatible type.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JCRVLT-403) Clarify usage of package type "application" for overlays
[
https://issues.apache.org/jira/browse/JCRVLT-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-403:
---
Description:
According to JCRVLT-170 it is not allowed to use {{includes}} or {{excludes}}
below a filter rule for {{application}} packages. This is a pretty common
pattern though for including overlays in an apps package to enforce creating
the ancestor nodes with the right type.
See also
https://issues.apache.org/jira/browse/JCRVLT-170?focusedCommentId=17016199&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17016199
The use case of two different apps packages providing overlays below the same
ancestor node should be supported (with both apps packages not knowing anything
about each other) and still ensuring that the right node type is being created
for ancestors.
There must be a way of enforcing a certain ancestor node type during import and
creating it in case it is not yet there, and failing in case if the ancestor is
there with a different/incompatible type.
was:
According to JCRVLT-170 it is not allowed to use {{includes}} or {{excludes}}
below a filter rule for {{application}} packages. This is a pretty common
pattern though for including overlays in an apps package to enforce creating
the ancestor nodes with the right type.
See also
https://issues.apache.org/jira/browse/JCRVLT-170?focusedCommentId=17016199&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17016199
The use case of two different apps packages providing overlays below the same
ancestor node should be supported (with both apps packages not knowing anything
about each other) and still ensuring that the right node type is being created
for ancestors.
> Clarify usage of package type "application" for overlays
>
>
> Key: JCRVLT-403
> URL: https://issues.apache.org/jira/browse/JCRVLT-403
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.4.4
>
>
> According to JCRVLT-170 it is not allowed to use {{includes}} or {{excludes}}
> below a filter rule for {{application}} packages. This is a pretty common
> pattern though for including overlays in an apps package to enforce creating
> the ancestor nodes with the right type.
> See also
> https://issues.apache.org/jira/browse/JCRVLT-170?focusedCommentId=17016199&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17016199
> The use case of two different apps packages providing overlays below the same
> ancestor node should be supported (with both apps packages not knowing
> anything about each other) and still ensuring that the right node type is
> being created for ancestors.
> There must be a way of enforcing a certain ancestor node type during import
> and creating it in case it is not yet there, and failing in case if the
> ancestor is there with a different/incompatible type.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
