[
https://issues.apache.org/jira/browse/SLING-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306856#comment-17306856
]
Ashish Chopra commented on SLING-9871:
--------------------------------------
hi [~bdelacretaz],
bq. modified your example using the above "fragment names and dependencies"
suggestion, slightly simplified, which would allow us (in a repoinit
preprocessor probably) to reorder those fragments correctly, whatever the
features aggregation order is.
Thanks for running through my example. I agree that "ability to specify
feature-file (or, as in your proposal, named-fragments within feature-files)
ordering" will solve the issue being discussed in this JIRA.
[As expressed
above|https://issues.apache.org/jira/browse/SLING-9871?focusedCommentId=17306210&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17306210]
I'm not sure if this augers well for a broader repoinit design. i.e.,
* would developers be able to add named FRAGMENTs and dependencies around all
directives the repoinit supports?
** if no, would it be a fatal error to do so for directives other than {{set
ACL}}?
** if yes, would it be possible for repoinit to enforce order in cases where
other mechanisms exist (and would indeed dictate) the final order? (I'd think
the answer is "no" [0]). Would it be OK to see these interdependencies as a
hint the actual artifact processor can ignore? (I think the answer is yes)
* is there a vision for named FRAGMENTs to fulfill other functions beyond
specifying dependencies (and thus processing order)? (a few wild ones I could
think of, conditional inclusion/exclusion? multiple executions/passes of
certain fragments? absolute processing order (a la start-level)?
cross-feature-file references?)
* ... ?
That said, I'm not well versed with the repoinit implementation to ascertain if
FRAGMENT support addition will be trivial or complex (I'd expect that to be one
of the factors in deciding amongst the proposals).
bq. Assuming that works at the JCR level, which Angela's "not guaranteed to
result in a new ACE being added at the end of the list" comment might
challenge, depending on the details of that Oak behavior.
I reckon that's one advantage of the FRAGMENTs approach - i.e., it only allows
specifying the order in which repoinit would process the {{set ACL}} directives
(thus specifying the relative order), without attempting to make an (implicit)
claim about the absolute final order of the ACEs.
[0]
bq. (e.g., content-package installation - no matter how the dependencies
withing fragments are specified, the eventual install order will be dictated by
dependency chain built using dependent-package info embedded in the
content-package. Similarly, for bundles the actual startup order is dictated by
start-level, followed by package-import-directives)
> Specifying order of ACEs through repoinit directives
> ----------------------------------------------------
>
> Key: SLING-9871
> URL: https://issues.apache.org/jira/browse/SLING-9871
> Project: Sling
> Issue Type: Improvement
> Components: Repoinit
> Reporter: Ashish Chopra
> Priority: Major
>
> As of writing this, repoinit processor (among other things not relevant to
> this JIRA) collects {{create path}} statements and {{set ACL}} statements
> declared in all the feature-models applicable to feature-aggregate under
> consideration.
> Upon repository initialization, it applies all the {{create path}}
> statements, followed by all the {{set ACL}} statements. However, the order in
> which {{set ACL}} statements declared across feature models are applied isn't
> defined (currently, it seems to be based on feature-model-name,
> alphabetically ascending).
> This causes issues at times because we want the order of the ACEs to be
> maintained (e.g., "deny"s for everyone at a given path must be the first ACE,
> followed by "allow"s for specific, non-system-user principals)
> Repoinit should be able to support this requirement.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
