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]

Reply via email to