[
https://issues.apache.org/jira/browse/SLING-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306963#comment-17306963
]
Bertrand Delacretaz commented on SLING-9871:
--------------------------------------------
bq. If we can assume that we only want dependencies at the ACL level, perhaps
we can make the language more compact...
My plan would be more to make the fragments thing a "preprocessor" concept and
process them before parsing repoinit statements, purely at a text level, so
something like
{code}
FRAGMENT one DEPENDS ON three
some text that's not even valid repoinit statements
create path /one
END FRAGMENT
FRAGMENT two DEPENDS ON three
set ACL for assets-users
allow jcr:read on /conf
end
END FRAGMENT
FRAGMENT three
# just a comment here
END FRAGMENT
{code}
Would result in the following text being passed to the repoinit parser:
{code}
# FRAGMENTS processed in this order: three, one, two
# just a comment here
some text that's not even valid repoinit statements
create path /one
set ACL for assets-users
allow jcr:read on /conf
end
{code}
(which is not even a valid repoinit script but that doesn't matter at the
FRAGMENTS level)
I think that's the simplest thing to implement and (if [~ashishc] agrees)
solves the problem, and can apply to any repoinit statements, it's just an
aggregation thing that's not directly related to the language syntax.
bq. This also has a small advantage of not requiring us to name fragments for
reordering purposes.
Good point, if we want to make names optional we could also use
{code}
FRAGMENT DEPENDS ON three
{code}
But requiring unique fragment names might make things clearer and
troubleshooting simpler (see the FRAGMENTS comment in the output above)
> 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)
