[
https://issues.apache.org/jira/browse/SLING-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17308203#comment-17308203
]
Eric Norman edited comment on SLING-9871 at 3/24/21, 10:05 PM:
---------------------------------------------------------------
[~bdelacretaz] Trying to catch up here. In general I don't have a problem
with the "named blocks" concepts and I can see how it could resolve the ACL
ordering troubles. It actually reminds me a lot of RequireJS syntax to get JS
code blocks to run in a specific order.
For brevity, maybe consider "DEFINE" instead of "FRAGMENT" and "REQUIRES"
instead of "DEPENDS ON" to get something like this:
{code:java}
DEFINE one REQUIRES three
some text that's not even valid repoinit statements
create path /one
END DEFINE
DEFINE two REQUIRES three
set ACL for assets-users
allow jcr:read on /conf
end
END DEFINE
DEFINE three
# just a comment here
END DEFINE
# no name, only requires other blocks?
DEFINE REQUIRES three
create path /two
END DEFINE
{code}
On a related topic, supporting named blocks of statements in repoinit could be
useful in filling a gap in aggregation for clash resolution. I don't see any
mechanism at the moment for conflict resolution in repoinit code. It looks to
me that slingfeature-maven-plugin aggregate supports configuration (i.e.
artifactsOverrides and configurationOverrides) to define how to resolve clashes
for artifacts and configuration, but nothing for resolving clashes in repoinit
code. I could imagine similar configuration for repoinit code that could
define how to resolve same-name block clashes (i.e. USE_FIRST, USE_LATEST,
MERGE_FIRST, MERGE_LATEST).
was (Author: enorman):
[~bdelacretaz] Trying to catch up here. In general I don't have a problem
with the "named blocks" concepts and I can see how it could resolve the ACL
ordering troubles. It actually reminds me a lot of RequireJS syntax to get JS
code blocks to run in a specific order.
For brevity, maybe consider "DEFINE" instead of "FRAGMENT" and "REQUIRES"
instead of "DEPENDS ON" to get something like this:
{code:java}
DEFINE one REQUIRES three
some text that's not even valid repoinit statements
create path /one
END DEFINE
DEFINE two REQUIRES three
set ACL for assets-users
allow jcr:read on /conf
end
END DEFINE
DEFINE three
# just a comment here
END DEFINE
# no name, only requires other blocks?
DEFINE REQUIRES three
create path /two
END DEFINE
{code}
On a related topic, supporting named blocks of statements in repoinit could be
useful in filling a gap in aggregation for clash resolution. I don't see any
mechanism at the moment for conflict resolution in repoinit code. It looks to
me that slingfeature-maven-plugin aggregate supports configuration (i.e.
artifactsOverrides and configurationOverrides) to define how to resolve clashes
for artifacts and configuration, but nothing for resolving clashes in repoinit
code. I could imagine similar configuration for repoinit code that could
define how to resolve same-name block clashes (i.e. USE_FIRST, USE_LATEST,
MERGE_FIRST, MERGE_LATEST).
> Allow for reordering aggregated repoinit fragments
> --------------------------------------------------
>
> 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)
