Standalone core dependency problems with Maven 3

Development
1

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.

2

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.

3

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.

4

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 artifacts.

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.