I use a shell script to build and install my OpenMRS module in a local server for testing; the server is created by “mvn openmrs-sdk:setup-platform” and the script installs the module by calling “mvn openmrs-sdk:install-module”. As of this morning, this has started failing. The build script itself hasn’t changed; the calls to “mvn openmrs-sdk:install-module …” worked up until yesterday, but now report the error:
[ERROR] Could not find goal ‘install-module’ in plugin org.openmrs.maven.plugins:openmrs-sdk-maven-plugin:2.0.1 among available goals upgrade-platform, install, help, setup-platform, setup, upgrade, reset, run, setup-sdk, uninstall, create-module, create-platform-module, delete -> [Help 1]
Did something recently change in the SDK plugin?
Thanks for your help!
Thanks for your reply! Options “install-module” and “uninstall-module” works only for 2.0-beta version. Last week we released the final SDK 2.0-stable version, where we shortened task names to “install” and “uninstall”
Please see SDK documentation for more details
Thanks, Dmytro! That helps get my build working again.
It doesn’t seem good that there would be an incompatible change like this in the Maven plugin release, though. Script that invoke the plugin just as “mvn openmrs-sdk:install-module” were previously using plugin version 2.0 and now are using version 2.0.1. An incompatible change from 2.0 to 2.0.1 is surprising because 2.0 to 2.0.1 is just a patch-level version increment. The plugin is automatically upgraded from 2.0 to 2.0.1, causing all builds that use this goal to spontaneously break without warning.
How do you think this might be prevented? Some ideas: Is it possible that the 2.0-beta version was not intended to be released as 2.0? Should 2.0-stable have been released as 3.0 instead of 2.0.1, so that the incompatible change didn’t break everyone? Or is there some other mechanism in Maven to prevent upgrades like this from happening automatically? Should support for “install-module” have been kept in addition to “install” until version 3.0? Or am I invoking the plugin incorrectly?
I am sorry that I am not familiar enough with Maven to know what mechanisms are available, but I think it’s worth considering how to prevent breakage like this.
As Dmytro said the change was introduced in the final 2.0 version. In other words 2.0-beta had install-module and 2.0 had simply install. We commit to using simply “install” from now on.
If you want to use a specific version of the sdk then you can call it in your script like:
Otherwise if you do not specify version then maven will be periodically checking for the latest version and upgrading to use it.
Let’s suppose I want to write a build script that picks up bug fixes you release, but does not spontaneously break. What versioning practice would you recommend?
We suggest that everyone follow the Versioning conventions as you imply (bug fixes in maintenance versions, backwards-compatible features in minor versions, and backwards-incompatible changes in major versions).
If you went from 2.0-beta to 2.0.1, then all bets are off. There are no guarantees about features from beta to final release.
If you went from 2.0.0 to 2.0.1 and found non-backwards-compatible changes, then that does represent the convention being broken. Either the conventions were broken for a good reason or by mistake. It’s certainly reasonble to assume that going from 2.0.0 (non-beta) to 2.0.1 or 2.1 should not break scripts.
Thanks! It sounds like the confusion just has to do with version numbers. It looked to me (based on output from Maven) like this was from version 2.0 to 2.0.1 — I didn’t see a version named 2.0-beta. Or was I misunderstanding how the version numbers are represented?
As Rafal previously said, “install-module” task was ONLY in 2.0-beta version. Once we released stable 2.0 version, we renamed “install-nodule” to "install’. So, if you saw a “install-module” task - it was certainly 2.0-beta version.