Persist some JHipster settings globally to save time when creating projects - jhipster

I'm using JHipster a lot to try out new things
Some settings I usually don't change.
For example: on the internationalization step I usually choose "Englisch" as main language and "German" as translation language.
Also, I want to have some plugins from the marketplace always inside the project.
Can I place a file with some options somewhere so JHipster applies those to all new projects I create?

You can use a jdl-file to persist application settings, too, see: https://github.com/jhipster/jdl-samples (e.g. https://github.com/jhipster/jdl-samples/blob/master/microservice-ecommerce-store-4-apps.jdl).
Here is some documentation, which options you can use for your application: https://www.jhipster.tech/jdl/applications (e.g. enableTranslation, nativeLanguage, languages etc.)

Related

Can we use many language on Github Action Configuration

I want to create CI on Github Action for QA Automation. But there is multiple language are use to install dependecies. Can i use NodeJS and Golang at the same file?
I read the documentation of Github Action, but there is configuration for each language not both. Any reference or idea i can use?
In short, you write a manifest file (in YAML) and tell GitHub Actions build agent(s) to execute the commands you wanted in an automatic way. See, there is nothing there bind to a single programming language.
You see per language samples/tutorials, simply because that's how new users/developers to get started with a CI/CD system, and it is easy to write up the necessary steps if focusing on the ecosystem of a single programming language.
The underlying GitHub Actions build machines (if managed by GitHub), however, have almost everything pre-installed, so of course you can use Node.js and Golang tools in the same manifest and you don't need any specific reference.
Open the image pages and learn what tools are preinstalled if you like.
Try it out by combining multiple manifests into the single one, and you will see how it works out.

Shopware 6 administration build only plugin

Is there a command to build only the administration part of a specified plugin? Right now I am building the whole administration to build the public resources for the plugin, which of course takes more time. Since every plugin has it's own resources, shouldn't it be possible to do this?
Since Shopware 6.4.8.0 it seems to be possible to only build the extensions (not a single one, but at least only extensions) by adding the environment variable SHOPWARE_ADMIN_BUILD_ONLY_EXTENSIONS=1
There are no out-of-the-box scripts to selectively build only one module.
The build is based on one single webpack config in vendor/shopware/administration/Resources/app/administration which includes each extension's code as as submodule.
If you are asking to speed up development, you might want to use bin/watch-administration.sh which should only rebuild changed files when you save them.

How can I synchronise configs such as tsconfig, eslintconfig, prettier across different projects?

My team develops different micro services with Node, using tools such as Typescript, ESLint, and Prettier among others. These tools have configuration files that are located in the project root. (This is important, because git submodules, as far as I understand, can only be used on selected sub-folders).
We change this configuration files from time to time, as our tools improve and offer new capabilities. However, its tiresome to copy these new settings to all the different services we maintain. What's a good way to sync them between different projects and keep things DRY?
You can create a npm-package and use it with all projects. That way you will also get versioning for your settings.

Why are SAP Commerce Cloud recipes not recommended for Production, but the set-up instructions usually mentions using recipes?

In Installing SAP Commerce Using Installer Recipes and Installer Recipe Reference, there is a comment that says something like:
The installer is currently only intended to install SAP Commerce in
development environments or for demonstration purposes. Do not use the
installer to install SAP Commerce in a production environment.
However, guides like Customizing the Accelerator with extgen and modulegen usually mention recipes:
On Windows: install.bat -r b2c_acc_plus
So, how do you really set-up a project from scratch? Do you start with recipes, or do you start with ant modulegen?
I don't see clear instructions (or best practice) on how I should build a B2C/B2B application from scratch for development and then preparing it for Production. (Maybe there is a gap in the instructions, or I just don't know where it is)
Even the Installing SAP Commerce Cloud for use with Spartacus guide mentions starting with a B2C recipe. Does this mean that the starting point of building a SAP Commerce project is to use recipes? Are there cases where you would not use a recipe, and build everything from scratch using ant modulegen and ant addoninstall?
It is not recommended to use recipe for direct installation on production. Reason being it installs a preset of hybris extensions which might or might not be needed for your requirements, also it might not be a allowed to use under the license you got.
However, when you start your development, you can use recipe to give your development a quick start. It generates the raw structure for your e-commerce application which you would need to customize and later deploy on your production.
how do you really set-up a project from scratch? Do you start with recipes, or do you start with ant modulegen?
Well, You can use any of those. If you are looking for difference, it has already been answered here
how I should build a B2C/B2B application from scratch and prepare for production?
For production hybris deployment procedure refer this.
NOTE :
a) recipe installation does more than what you can achieve using modulegen like complete installation, configuration and initialization for a running e-commerce example. I think once you go through above links, you will have a much better understanding on this.
b) When you go with recipe, it will install related extensions which you might not want to use or don't have production license for that. Please be considerate to review and disable such extensions,
Thanks
A few more points adding to the answer by www.hybriscx.com
Generally, the integrations in a recipe are mock integration e.g. payment integration as the purpose of a recipe is to provide a ready-to-use demo/reference application (store).
The data (catalog, users & password, usergroups, roles, promotions etc.) in a recipe are sample data. The same goes with the look-n-feel (logos, colour, layout etc.). Every business requires its specific data and look-n-feel.
The system configurations/properties (e.g. memory configuration, logging configuration etc.) may be optimised for the demo purpose but the production setup may require a different configuration. On the same line, configurations like hosts, ports, encryption etc. are general purpose configurations and a production environment may need to change them.
The database set up by a recipe is generally HSQLDB which is only good for development/demo.

How to override hybris platform files other than customize

So, I can see many files under customize folder under platform.
Is there any other way to oveerride platform in general other than putting it in customize folder?
If we have to override some OOTB file there are two ways:
1) If its in some extension, we can create customized extension and do our changes.
2) Add stuff into customize folder and do ant customize.
What if OOTB file is in platform? Is there any other way?
I expect to customize platform without adding it to customize folder.
Is the function/bean you want to override is injected through Spring?
If no, and you need to override say some jar, class or xml. You have choice of ant customize or buildcallbacks.xml
If yes, it's no different than overriding any other beans from parent extension. The only thing is that you will not need to create an extension dependency as platform is available globally.
For example : If you wish to override some function in DefaultCatalogDao to give your own implementation. You can do it like...
Create your own implementation extending the platform related service
Inject your custom bean with alias of the defaultCatalogDao
<alias alias="catalogDao" name="customCatalogDao"/>
<bean id="customCatalogDao" class="......CustomCatalogDao" parent="defaultCatalogDao"/>
For Commerce Cloud
You can change platform files using customize folder in Commerce Cloud V2 too. You would need to create a folder in your custom repository with name _CUSTOMIZE_ and then as you do in non cloud version, add your files (with exact folder structure as in platform).
Once you creare above folder, CCV2 build strategy automatically picks and deploys it, without any additional configuration.
Hope it helps!
Using buildcallbacks you can replace the files even the files in platform jar .
You can simply copy paste your file or write your own shell script to execute it and copy file to platform but how would it be different from ant customize. And why would you want to go away from standard hybris practices? Would that give you any extra benefit? I am sure that would only lead to issues during upgrade etc. Its not spring bean injection where you could tell your platform to use your implementation instead on other. There is no sense in wasting time in finding something which doesnt go along with product best practices.

Resources