Yeah, that is the case exactly. Not sure there’s a good way around it that wouldn’t introduce a bunch more server-client coupling.
Yeah, that definitely makes sense.
@mksd & @mksrom, will @bistenes’ approach work with the folder layout convention proposed in RefApp 3.x? I mean, I know it can work, but do we see a way to make this the default/assumed convention that “just works”?
@burke isn’t that a question for @bistenes?
Maybe I’m missing something but what the SDK does usually is build the distro and then do its thing. Building the distro means relying on the build of the distro Maven project. In other words the SDK acts downstream of the distro project.
But if anything needs to be changed in the distro project to make the SDK tooling easier, let’s do it. It’s not too late since we haven’t released anything yet.
Actually, I’m just realizing that the RefApp 3.x layout doesn’t have an openmrs-distro.properties file. It seems like the modules are just listed in the POM.
So it seems completely orthogonal to what I’m working on here. But maybe the RefApp 3.x layout should instead be built around an openmrs-distro file?
The old Ref App (so to say) requires to maintain the openmrs-distro.properties file LHS keys in sync with the POM dependencies. That was always “ok” but obviously requires some additional attention.
Having some tooling that generates that file from the POM file would be ideal. Whilst writing this I realise that this piece of O3-minded tooling could be somewhere in the SDK?
Would this mean that we’d also want to define the microfrontends in the POM?
I do think it’s worthwhile to discuss whether the openmrs-distro.properties file is secondary, and generated from information in a distribution POM, or whether it is a primary artifact that is maintained and complementary to the distribution POM (or could stand alone and not require a distribution POM).
Maybe the answer is that both are valid options, as long as we build common standards in our distribution packaging.
The assumption I’ve been making is the the openmrs-distro.properties file (and / or some new openmrs-distro.yml file) would continue to evolve as a means to define an OpenMRS distribution in full, and that SDK and other tooling would be able to install a fully defined and operational OpenMRS instance with war, modules, owas, config, and microfrontends with just the configuration present in this file.
Interested in discussion more and hearing others thoughts.
Mike
Thanks @mseaton for sharing your thoughts. I realised that I had a draft response for @bistenes that I had left hanging… and now rather that posting it I’d suggest that we take this to a good ol’ TAC.
Cc @grace
1 Like
I’m not going to be around for next weeks TAC, so just some thoughts on this:
-
Currently the RefApp Docker images are built using the SDK build-distro command. Consequently, the “final” Docker image is a product of the openmrs-distro.properties file, the openmrs.sql file (these are the two things bundled in current Reference Application JAR file).
-
The openmrs-distro.properties is thus at the heart of the process that we use to setup both the community-run servers and local development servers. Moving away from it probably means we need to redesign large parts of the SDK.
-
I think it’s important to ensure that there’s alignment between how we are packaging RefApp 3.0 and how we encourage people to setup dev environments, at least for backend work. I.e., the more similar they are, the more we can trust that changes that work locally will continue to work when deployed. I’m pretty agnostic as to whether this means we keep things working as they are or just modify the SDK.
-
Although this is somewhat tangential, it’s probably good to think about the role that module-spa will play in the future, i.e., it seems pretty essential to the SDK being able to deploy MFs to a local server and to keeping OMRS deployable as a single bundled WAR.
-
Probably worth considering that we may need to maintain multiple kinds of Docker images, e.g., one fully bundled for the community demo environment and one not fully bundled for the community development environment.
2 Likes
IMO this is very critical for moving things forward
Rather than building this complexity into the SDK, pointing it to relevant distro.properties files would be the best way forward
2 Likes
Discussed in TAC call on 2021-06-28. General agreement on working toward a distro.properties (eventually a YML) as a single source of truth, generating POM contents as needed from it.
1 Like
@bistenes are you able to successfully compile the OpenMRS SDK? Some tests seem to be failing on the microfrontends assertion lines. [INFO] Running org.openmrs.maven.plugins.SetupIntegrationTest[ERROR] Tests run - Pastebin.com