Application Name: Reference Application Version Number: OpenMRS 3 .
Question: I am struggling to use the maven sdk to use the config files for the spa frontend modules. The config works perfectly when i use the dockerized distro. when i update the config-core_demo.json here, and run using docker compose up --build, i can see my changes. However, I am not able to setup the mvn openmrs-sdk. Can someone please help me with this? @mksd @dkayiwa
Thank you so much for reaching our @prateek_cs_india and not suffering in silence 
Thanks @grace. I have worked with 2.x in the past and I wanted to explore the micro-front end approach. It looks very exciting to me so far (off course I have a few minor config related challenges). I was wondering if we are planning to go on the micro-services side in the back-end as well with a multi-database model. For example, appointments go in a silo, the core emr-handles the patient data, and so on.
In the meantime, I would still need some help on the sdk configuration 
@prateek_cs_india What specific help do you need with the SDK?
Not yet. As for all our current use cases, a modular monolith with a single database, is the appropriate architecture.
@wikumc Can I configure the sdk to use a config.json file which could then be utilised by the spa files.
I am trying to achieve the feature using something similar to this file here
I see the npx openmrs tooling building/importing the assets into the ~/openmrs/<server_id>/frontend/ directory.
No, we currently don’t have that feature in the SDK.
I do believe this is possible, based on what I learned yesterday from @ibacher , especially if you package your config.json in a content package and deploy both your frontend and content via a distribution. Is that correct @ibacher ?
Yes. I think you also need:
spa.configUrls=/openmrs/spa/openmrs-config.json
In your distro.properties.
@ibacher I tried with
spa.configUrls=/openmrs/spa/openmrs-config.json
however it did not reflect my changes when I restarted the server using the sdk.
Do you think we can upgrade the sdk itslef to take in additional parameters for the build config file(s)? What I am suggesting is to achieve something similar to what we have in the distro’s Dockerfile here.
eventually we could see:
mvn openmrs-sdk:setup -DspaConfig=spa-config.json
spa-config should have info about the build and assemble file and the sdk should be able to pick each of those configs and eventually run the npx openmrs tooling with the right arguments, if available.
Can I explore this option and maybe work on it?
@prateek_cs_india As @mseaton said above, this only works if your frontend configuration is in a content package. Just adding what I suggested isn’t everything that needs to be done. (And passing the frontend config as an option to the SDK isn’t really going to be a long-term sustainable thing, so I’d rather we not pursue that).
The frontend configuration is really a part of the frontend system. The thing that’s currently not working is that there’s no where you can put a config.json that will be magically added by the SDK to the frontend. If the frontend configuration is provided as part of a content package it gets added in. This is basically a result of how the SDK commands are structured vs how the Docker stuff is setup.
I feel like if we can have a wizard of sorts which prompts inputs from the end user(s) perhaps not exactly a SDK, which could help configure the installation on a machine - be it local, UAT or for PROD, could a newbie get started quicker. I went through the docs and felt ever so confused on which path to take. I using a distro as of right now, and I am trying to build a small script which sets up everything based on a few prompts/input-file. I will share an update if I get it working.
The SDK is intended as that tooling. I think what needs to be recognised, though, is that not all parts of O3 have been integrated into that tooling, because it’s not immediately clear how all of that makes sense. FWIW, we need to extend the SDK, we just need to also be careful about what this config file is and where it’s expected to be drawn from as part of a distribution. The goal here isn’t just to get newbies up and working quickly, but also have tooling that’s robust enough to work with existing distributions that are described. The reason that it hasn’t been dealt with is that we haven’t yet worked out the best way to include it (if you just want to modify the config, use the O3 implementer tools to do so live; it’s a much better experience than modifying a file and restarting things).
To be completely transparent about this, it’s the config_core-demo.json file that’s part of the distribution that’s the non-standard part. That’s not necessarily how things are expected to be packaged and deployed and I wouldn’t use it as a model of anything. It’s a quick hack to demonstrate using the configuration system in a distro.