You rock! 🤘

BTW, if you have any questions/need help, just ask here or find me on LinkedIn

Sure, thanks.

Currently I'm fighting with my IDE and gradle-script support there, but I think i've got a working version of the commerce part.

Since the commerce accelerator is deprecated, I wonder if the template should still provide the accelerator storefront by default, or whether this should be behind a feature toggle?

Let's hide it behind a toogle. Default should be new OCC APIs only + Spartacus

I'm afraid toggling the acceleratorstorefront is not as easy as I thought, because the current process uses modulegen. Yacceleratorstorefront is still part of the accelerator module template, despite being deprecated. Would it be better to switch to extgen? Or should we rather stick with modulegen and still have the yacceleratorstorefront?

Also: I'm uneasy with uploading the cloudhotfolder extensions since I'm not licensed to do that. Wouldn't it be better to have them as dependency in the dependencies folder?

Or should we rather stick with modulegen and still have the yacceleratorstorefront?

Still use modulegen but delete *storefront afterwards?

That's what I went for, I hope I caught every trace of the storefront.

Should the cloudhotfolders be optional too? As far as I understand it, we could instead provide an alternative hotfolder configuration (plain folder, without azure) in the dev config for testing. Then the azure cloud hotfolders will only be loaded in the cloud.

If someone wants to test azurecloudhotfolder specifics they still could put them in the dependencies folder and unpack them?

Then I wouldn't need to commit copyrighted Code into Github ;-)

we could instead provide an alternative hotfolder configuration (plain folder, without azure) in the dev config for testing

Unfortunately not, the cloud hotfolder logic is different enough from the stuff in acceleratorservices to cause issues if not properly tested.

Let's add a note/step to download the extensions from the SAP Note 2817992, to avoid having the code in the template.

Plus a flag to optionally disable cloud hotfolders, if it isn't too much to ask.

Man, this keeps dragging on...

I updated the description with the current version and TODOs

The part of making the azurecloudhotfolders optional is easy I think, just haven't found the time to do it yet.

But with the Storefront It feels like a lot has changed. The environment.ts files have disappeared so the patches - at least partly - don't match anymore. I currently have no idea what a storefront configuration could look like that works locally but also lets you configure the endpoints and the CCv2 Base url in the cloud like described in the documentation

• https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT/eaef8c61b6d9477daf75bff9ac1b7eb4/1f30af7b54c0493096911bf404d0967d.html?locale=en-US
• https://help.sap.com/docs/SAP_COMMERCE_CLOUD_PUBLIC_CLOUD/b2f400d4c0414461a4bb7e115dccd779/1c26045800fa4f85a9d49e5a614e5c22.html?locale=en-US

Any ideas?

thank you for keeping at it!

re. composable storefront:
I think the patches are already obsolete. It has been I while since a set up a new storefront project from scratch, but it should just work ootb now. e.g.OCC_BACKEND_BASE_URL_VALUE is included by default in index.html etc.

Let's add a note/step to download the extensions from the SAP Note 2817992, to avoid having the code in the template.

Plus a flag to optionally disable cloud hotfolders, if it isn't too much to ask.

The flag was too complicated on first glance, I found no nice way to persist the initial decision whether it is needed so I just put it in the Readme.md for the user to handle it. They can either download the zip file or remove the dependency on bootstrapping it from the build.gradle.kts.

Apart from that I think I'm done for now. There is still a lot room for improvement, but I think it's definitely better than before.