discussing the options with carsten off-list a bit there are multiple ideas how bundles with Sling-Initial-Content could be processed:
a) the way I described initially, extending the feature-cpconverter and sling-feature-analyzer to support those bundles and extract the contained Sling-Initial-Content to a content package to be deployed to the immutable part of the repo. probably activated as option in both tools. b) the same can be done earlier in the build process: when building the individual maven module of a bundle with Sling-Initial-Content a Maven plugin could take this content and create an attached content package artifact (with a classifier) in parallel to the bundle artifact, and remove the Sling-Initial-Content in the same step. in the further deployment steps those two artifacts are treated separately as bundle and content package. variant b) is probably a bit more easier to achieve or more transparent what's happening. but it does not work for bundles you have no control over that already contain Sling-Initial-Content. in the long-term it might make sense to support both, sharing the same code base for extracting the Sling-Initial-Content to a separate content package. stefan >-----Original Message----- >From: Carsten Ziegeler <[email protected]> >Sent: Wednesday, February 3, 2021 3:27 PM >To: [email protected] >Subject: Re: [RT] Make bundles with Sling-Initial-Content first-class >citizens in feature model tooling > >Hi Stefan, > >I think we have more than two worlds - it's a multi-verse > >For example, for our projects we don't want to have initial content at >all - thats why we need to have an analyser checking for this. > >If I think about other projects I can envision that some are fine with >initial content for an immutable repository - but not for a mutable >repository. > >And others might be fine with whatever they get. > >I think thats a choice every project should be able to make - it's like >some projects like to code OSGi services with Declarative Services, some >want to do via framework api, others want to use CDI etc. There is no >right or wrong here. > >So for the analyser we need to have this configurable. We can discuss >what we think is the best default for Sling based projects of course. > >For the cpconverter, I think it depends on where or who is using this. >So you might want to enable converting initial content to a content >package or you might be fine with ignoring it or you use the "normal" >way of the contentloader bundle at runtime. It's again the users choice. > >Regards >Carsten > >Am 03.02.2021 um 15:12 schrieb Stefan Seifert: >> hello carsten. >> >> can you give some more details about the "setups and requirements" that >differ? >> >> i fear if we introduce a switch to distinguish on those things we create >different "worlds" of scenarios which all have to be maintained and tested >separately in the already quite complex toolchain around feature models. >> >> and why is it exactly the Sling-Initial-Content support which will be the >pivot that separates one world from the other? >> >> stefan >> >>> -----Original Message----- >>> From: Carsten Ziegeler <[email protected]> >>> Sent: Wednesday, February 3, 2021 6:51 AM >>> To: [email protected] >>> Subject: Re: [RT] Make bundles with Sling-Initial-Content first-class >>> citizens in feature model tooling >>> >>> Hi, >>> >>> in general, I think those changes make sense. However, project setups >>> and requirements differ - so I think it makes sense to have an analyser >>> that forbids initial content in bundles. So we either make the existing >>> analyser configurable or have two analysers. >>> >>> I think the same applies to the cpconverter: having a switch which >>> either allows initial content and creates the content packages as you >>> suggest or fails. >>> >>> Regards >>> Carsten >>> >>> Am 02.02.2021 um 23:38 schrieb Stefan Seifert: >>>> currently, bundles with Sling-Initial-Content have not special support >in >>> the feature model tooling and when used with composite nodestore. >however, >>> they work just fine e.g. in AEMaaCS because during the image build phase >>> the contained content gets extracted and baked into the docker image. at >>> runtime, the Sling JCR content loader produces a warning about the >locked >>> down /apps folder which can be ignored, because the content is already >>> there and does not need to be extracted again. however, it's probably >>> currently working only due to "lucky circumstances" in the current >process >>> of cloud build pipeline. >>>> >>>> the sling-feature-analyzer [1] is currently looking out for bundles >with >>> Sling-Initial-Content and produce a warning if it founds any. >>>> >>>> Sling-Initial-Content is around for years and i would like to make >>> bundles with it "first-class citizens" in the world of feature models >and >>> composite node stores. Without having looked into details of the current >>> feature model toolchain a "full support" might look like this: >>>> >>>> 1. the sling-feature-analyzer should be changed to accept bundles with >>> Sling-Initial-Content in general, but check the configured path to make >>> sure they point only to immutable areas in the repository. >>>> >>>> 2. in the feature-cpconverter [2] could be extended to detect bundles >>> with Sling-Initial-Content and probably convert the contained content to >a >>> content package and include it in the feature model for further >processing. >>>> >>>> WDYT? >>>> >>>> stefan >>>> >>>> [1] https://github.com/apache/sling-org-apache-sling-feature-analyser/ >>>> [2] https://github.com/apache/sling-org-apache-sling-feature- >cpconverter >>>> >>> >>> -- >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> [email protected] > >-- >-- >Carsten Ziegeler >Adobe Research Switzerland >[email protected]
