You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "anchela (via GitHub)" <gi...@apache.org> on 2023/02/17 12:45:58 UTC

[GitHub] [sling-org-apache-sling-feature-cpconverter] anchela commented on pull request #157: SLING-11777

anchela commented on PR #157:
URL: https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/157#issuecomment-1434593401

   > but I believe he is a bit more in favour to use repoinit statements instead (original approach) 
   
   imho it depends on what you want to achieve.
   repoinit has less flexibility (i.e. there are not different import-modes and ac-handling flags, the filter-roots, etc etc) but that also makes it less brittle IMHO.
   
   one particular (but notable) difference: repoinit create path statements will NOT change the primary type if the node already exists, while content packages may change it depending on the import mode and the filters generated
   
   if the primary type should be overwritten one has to use the new 'ensure path' statement.
   
   so, unless you actually need the extra flexibility from content packages (e.g. because sling initial content also has an extra but slightly different amount of flexibility... and then we might have to find a best-effort match), i would also opt for repoinit.... but as i said... the lack of flexibility also comes with a price given that initial-content has more flexibility.
   
   WHY did try to support sling initial content 😢 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@sling.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org