Recently I moved all the builds in our CI to maven 3.
Turns out it broke the Openmrs core standalone.
You can reproduce the problem locally:
$ rm -rf ~/.m2/repository/org/openmrs/api/openmrs-api/1.12.0-SNAPSHOT/
$ mvn3.2.3 clean package -Dopenmrs.version=1.12.0-SNAPSHOT -Dopenmrs.war.path=war/openmrs.war
(it fails fast enough, no need to actually create the war anywhere).
The problem is related to the fact that we are defining dependencies of the liquibase plugin on pluginManagement. Apparently maven 3 is not using the defined on the pom file to download those artifacts. Upgrading the plugin made no difference, as expected.
I have heaps of questions, like: why do we need to define a openmrs dependency as a dependency of an external plugin? Why isn’t it a regular dependency?
That said, if we are relying on a snapshot from another repository, we need to build them just after using (same Bamboo job) and use -nsu to prevent maven of downloading newer snapshots from nexus (preventing race conditions between builds using the same repository). I did those changes, but I need someone to check the standalone still sane.
I believe the openmrs dependency is there for the liquibase plugin to be able to access changelog files i.e. liquibase-schema-only.xml and liquibase-update-to-latest.xml, which come from openmrs-api. I’m guessing it was put there after finding out that the plugin cannot access those files from a regular dependency, but it could be tried again.
I think that I started that pattern. I was trying to be able to have a
maven task that would create and set up the OpenMRS database from the
command line (by running the liquibase changesets in OpenMRS).
If there’s a better way to do this, we should switch to that.
In OpenMRS context, I think it makes heaps of sense to use SNAPSHOTs from
another repository. It’s a decision, the same way as using only released
But when working SNAPSHOTs, we need to make sure we are always using the
correct ones - from the same commit. I’ve changed the build a little but,
so the way the build is set now is pretty reliable (we are using the jar
and war from the same commit, with no external influence of the deploy from
core). I did that building everything on the same task, and preventing
maven to override snapshots with -nsu command line.
I can try to set the dependency as a regular dependency later to see if it
fails; if on the past it was failing for regular dependencies, maybe it was
a maven bug? I can test that assumption as well.