As discussed on the Dec 18th TAC call (see notes here), Iniz 2.1.0 will eventually be released with the new Iniz Validator embedded. And, before the 2.1.0 release, this new tool can be tested through the latest snapshot of Iniz.
I am kindly requesting for you to do so as your feedback will be invaluable ahead of the 2.1.0 release.
For the devs out there and for the record here is the PR:
(Special thanks to @ibacher who actually did review it, kudos!)
In a nutshell the Initializer Validator is a standalone fatjar to make dry runs of your OpenMRS configs and to report on any errors. This enables developers and implementers to be warned well ahead of time that a config would fail when loaded on real OpenMRS instances.
For business analysis profiles to use it on their local machines and ensure that all is well with the OpenMRS configs that they are putting together.
To fail invalid OpenMRS configs builds. That would be mainly useful for CI processes, but also for developers of course, ahead of pushing.
At Mekom and PIH there is certainly a lot of interest to start modifying the current OpenMRS configs CI builds so that they trigger the validation. And as suggested by @mseaton during the Dec 18th’s TAC call, this could be done via PIH’ openmrs-packager-maven-plugin to make this an easy change in existing POMs. That’s probably the very next thing on our roadmap.
Finally, please note that a couple of other changes have been introduced as well, most notably:
Much much better and prettier logging.
The ability to control Iniz’ behaviour more finely through a handful of new runtime properties.
In a nutshell: The Initializer Validator is a standalone fatjar to make dry runs of your OpenMRS configs and to report on any errors. This enables developers and implementers to be warned well ahead of time that a config would fail when loaded on real OpenMRS instances.
@mksd we may have some bandwidth this quarter, what would need to be done to enable Iniz to load configs within a module? I would like to see us moving all new metadata to use Iniz within our current setup
Hi @ssmusoke, that sounds like an anti-pattern since the whole point of Iniz is to not have metadata configurations bundled into modules (I presume you meant OpenMRS module?)
Or can you detail more specifically what you are after?
FWIW @ssmusoke we’ll be talking a bit more about the Iniz Validator in this week’s TAC call - this Friday at 5pm EAT - you’re welcome to join and we could dive into more detail there too
@mksd In that case we shall keep using the current setup we are since our use cases go against the Iniz philosophy, which is sad but it is what it is a missed opportunity to have all of the distributions using a single metadata deployment approach
@grace as per above there is no need to go into more detail to save time for more important discussions
@ssmusoke if you don’t explain what you are after in details nobody will be able to tell you whether it can be solved through using an OpenMRS config or not.
I vaguely remember that you bundle everything in the .war file. In that case I’m sure there is a way to embed the config in there as well. I think your challenge is rather around packaging and deployment than anything else.
@mksd I have been asking the same question for the last 2 years, and I have even offered to get resources to make necessary additions to Iniz to support this, and you said that it is not within the philosophy of the module so how more fundamental does that get?
They are only changed centrally and never changed on site so never need to change
Architecturally it makes sense to move to Iniz which supports CSV for better management and consistency plus opens up the ability for non-developers to update using CSV file edits (Centrally managed still)
It is not a critical or important aspect of the implementation, infact it is one which end-users never see it just appeals to my personal drive to have the cleanest and simplest possible architecture solution
What I would imagine is maybe something like this:
The config artifact gets bundled into the .war (like all other Maven artifacts involved in its bundling).
Make a change in Core so that it knows that .zip artifacts with a configuration folder inside should be copied to the app data dir upon starting up.
The reason for 2 is because I remember that your installation process is simply 1) drop the new .war and 2) restart. Since there is no other CD processes to hook ourselves to, then the .war needs to be able to install the config where it should be.
One thing that you will have to do is flatten this metadata setup into an OpenMRS config. In other words a bunch of Iniz-compliant CSVs. That’s implementation-specific work that will have to be done.
(As a side note something that can make this work a lot easier is the resolution of this issue, but for all CSV-based domains. That’s WIP already btw.)
So, when you have your OpenMRS config, the standard practise it to maintain it as a separate config project (see those at Mekom or those at PIH for example.)
That project would be built into a Maven .zip artifact and bundled into your .war. And Core would take care of copying its content into the app data dir upon starting, that’s what I suggested in point 2 of my last post above.
P.S. That’s the kind of message we would hope to see soon on your repos soon too :
It’s because I never envisioned for a second for configs to be inside modules in any way, my mind is just avoiding this by default
In that case it’s probably about doing the necessary refactoring for this to be able to point to a resource path rather than a file system path. And maybe there is not much to do.
And… put in place a mechanism that ensures that your module has started before Iniz kicks in.
True in your case, but I need to point out that in the general case that’s one of the few things to do. The general case requires three things to do:
Setup of a backend config.
Setup of a frontend config.
Setup of a distro.
And there’s no custom module put together for a specific installation/implementation. I really need to state this again because that’s the ultimate architecture design that Iniz helps enforce (and that we’ve been able to use in all our Bahmni deployments, and that we intend to propagate to our OpenMRS 3.0 installations).
@ssmusoke so what @mseaton was saying in the TAC call ( ) is to do something like this in your module’s activator:
// 1. copy the configuration folder from your resources to the app data dir:
// ...
// 2. manually invoke Iniz' default loading:
Context.getService(InitializerService.class).load(true);
You don’t even really need to disable Iniz’ usual behaviour actually. It would be cleaner to allow to toggle it off but I think things will just work fine anyway (thanks to the checksums.)
Your module will need to depend on and require Iniz.
Just bringing this back up, while this is the ultimate architecture design for the future, there are implementations which still have the old approach that is not about to be replaced, thus it would be great to have the ability to be leveraged by older running sites too
:
) is to do something like this in your module’s activator: