out of current occasion I happened to implement a maven plugin for b), see [1][2], see [3] about the context/reason. with a slight difference: currently the plugin produces two additional classifier-files, but this could be extended easy.
having this in place as a workaround i'm more convinced that we should really implement https://issues.apache.org/jira/browse/SLING-10243 as part of the feature toolchain, so provide a solution for a) on the long run. solution b) is quite fiddly. i assume most part of the implementation of the maven plugin could be used for a), so it's probably not that big a step. stefa [1] https://wcm.io/tooling/maven/plugins/sling-initial-content-transform-maven-plugin/ [2] https://github.com/wcm-io/wcm-io-tooling/tree/develop/maven/plugins/sling-initial-content-transform-maven-plugin [3] https://wcm-io.atlassian.net/l/c/RjW85bye >-----Original Message----- >From: Stefan Seifert <stefan.seif...@diva-e.com.INVALID> >Sent: Friday, February 5, 2021 9:00 AM >To: dev@sling.apache.org >Subject: RE: [RT] Make bundles with Sling-Initial-Content first-class >citizens in feature model tooling > >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
