Once again an issue related to TRUNK-4986, i.e., upgrading Liquibase. As mentioned in the ticket, OpenMRS relies on a few custom Liquibase extensions, which are currently basically unmaintained (the code for these extensions is still in SVN). While I don’t think we need the old extensions, for core, and as part of my work on this issue, I’m eliminating the dependency on any of them for core. We do need Liquibase extensions for two things:
The modifyColumn extension is extensively used throughout many OpenMRS modules, including in the Ref App and quite possibly beyond. Thus we need a working version of this extension to be deployed with the platform.
For reasons discussed here, we’re targeting Liquibase 3.1.1. However, Liquibase 3.1.1 suffers from a bug that has been fixed in Liquibase 3.4 and newer. This bug is pretty trivial to fix, but the fix has not been backported, so I’ve used an extension to override the default CreateTable behaviour.
These two extensions need to be packaged somewhere, so I’m requesting that a new module be created for OpenMRS Liquibase Extensions in the GitHub organization. There’s no need to port the existing SVN code.
I first of all start by thanking you @ibacher for the great work you are doing for our platform and a couple of core modules. You seem to have an attraction to these complicated but useful tickets that most people are running away from!
Now getting down to your suggestion:
If you migrate the modifyColumn extension into a module, i guess that requires modifying the affected modules by adding a require_modules to their config.xml files. Correct? Would you find that better than just leaving the dependency in the core? At least for now?
As for the second extension, are you planning to add the compiled jar dependency to core?
So I probably misspoke when I said “module” I’m really just looking for an OpenMRS GitHub repo to store a maven project that will compile to a couple of JARs that the platform could depend on. My reasoning for wanting this in a separate space is that I actually want to discourage the use of the modifyColumn extension because, while it works well for MySQL and MariaDB, it’s very difficult to maintain in a way that could be used on, e.g., PostgreSQL or most commercial databases.
Currently, what I’ve done on my own machine is to add a new Maven sub-module to the core repository that stores these classes and then made the API depend on that sub-module. If that’s acceptable to have in core, I guess I could just commit it as-is.
I find this simpler and therefore like it more than having to maintain a separate repository for only one client, core.
And by the way, if it is just a few classes, do we have to even create a new maven sub module? Why not simply put them in the existing liquibase package?
Well, to be picked up automatically, Liquibase extensions need to be in the liquibase.ext package (or sub-packages like liquibase.change.ext). I can easily add that to the main API. Do you think that’s the way to go?
Since the only client that they serve is core, i would put them in. I do not see much gain in going through the extra work of a separate repository, for just a few classes. Here is an example of some spring framework classes, which we directly put into the core platform, instead of creating a separate repository for the dependency jar: https://github.com/openmrs/openmrs-core/tree/master/web/src/main/java/org/springframework
