Hi, There are some issue with RepoInit with regards to failure behaviour like [1] and [2] and the discussion initially raised in JIRA and/or GitHub PR was a bit tough I try to summarise the issue and status quo here in order to get some more feedback.
Most repoinit statements lead to an exception and prevent the SlingRepository from getting up and running. This has the advantage of assuring that the repo is in a certain state once the SlingRepository is up (although obviously the state might change afterwards). The drawback is that it is hard to debug/fix issues when not even the SlingRepository is up. The drawback might not be that severe once there is a flag to toggle that behaviour as proposed in [3]. The discussions around the multiple open PRs in https://github.com/apache/sling-org-apache-sling-jcr-repoinit/pulls kind of converged to: It is good to stick to that initial design goal, but fixing existing issues must be strictly backwards-compatible (in my own words). Please respond here if you have concerns with that approach. After we have some agreement let us also document the (intended) failure behaviour more clearly on https://sling.apache.org/documentation/bundles/repository-initialization.html and document where we deviate from that (for whatever reasons). With regards to fixing existing issues without breaking compatibility the proposal was to introduce either new statements/or at least a new option in case the behaviour is changed to stick more to the “fail in case statements cannot be applied”. So I already made a proposal for [2] in [4], please comment directly in [4] to share your thoughts. For [1] I have not a very good idea how the statement should look like, so I would appreciate some suggestions. Thanks for your input, Konrad [1] - https://issues.apache.org/jira/browse/SLING-10281 [2] - https://issues.apache.org/jira/browse/SLING-11736 [3] - https://issues.apache.org/jira/browse/SLING-8843 [4] - https://github.com/apache/sling-org-apache-sling-repoinit-parser/pull/27
