I now created https://issues.apache.org/jira/browse/SLING-10243 <https://issues.apache.org/jira/browse/SLING-10243> to track a). Konrad
> On 5. Feb 2021, at 08:59, Stefan Seifert <stefan.seif...@diva-e.com.INVALID> > wrote: > > 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 <cziege...@apache.org> >> Sent: Wednesday, February 3, 2021 3:27 PM >> To: dev@sling.apache.org >> 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 <cziege...@apache.org> >>>> Sent: Wednesday, February 3, 2021 6:51 AM >>>> To: dev@sling.apache.org >>>> 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 >>>> cziege...@apache.org >> >> -- >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org
