-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Versions #30
base: main
Are you sure you want to change the base?
Update Versions #30
Conversation
* Gradle 8.3 * Java 17 * SAP Commerce Cloud 2211 (probably not yet complete)
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? |
Still use modulegen but delete |
* update SAP Commerce * use sparse bootstrapping once the project is generated * fix generation with acc storefront
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 ;-) |
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. |
* Add tasks for downloading solr versions * Add tasks for unpacking cloudhotfolders from the dependencies folder
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
Any ideas? |
thank you for keeping at it! re. composable storefront: |
3738cb6
to
6dfbcec
Compare
( | ||
cd "$NAME" || exit 1 | ||
|
||
cat > .npmrc <<-EOF |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fibsifan
a simpler way to handle this would be using env vars in the npmrc.
e.g.
@spartacus:registry=https://73554900100900004337.npmsrv.base.repositories.cloud.sap/
//73554900100900004337.npmsrv.base.repositories.cloud.sap/:_auth=${RBSC_NPM_CREDENTIALS}
always-auth=true
now you can add the .npmrc
to your repo without leaking credentials and use the same config everywhere.
export RBSC_NPM_CREDENTIALS=abc1245
yarn build
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 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. |
Backend:
Frontend:
intended to fix #29
Out of scope for this PR: since the versions of Frontend, Commerce Cloud and Integrations package are now coupled, find a way to parameterize all of them,