OpenMRS SDK test failure

The OpenMRS SDK integration tests seem to be failing. A test called setup_shouldInstallPlatform1_11_5 is failing. It appears that platform 1.11.5 has indeed disappeared from jfrog: Index of public/org/openmrs/distro/platform

Could someone please try to reproduce and then advise? Just clone the repo and run mvn clean install.

Should I just change the version number being tested to, e.g., 1.12.1?

@burke @dkayiwa @mseaton

well at my side i get this building successfully,logs Microsoft Windows [Version 10.0.19041.985](c) Microsoft Corporation. All right -

1 Like

@bistenes - yeah, looks like that artifact is missing, which hopefully someone can investigate (@ibacher FYI). But yes, I would say just pick a different version that is present and have the test use that (eg. 1.11.7)

BTW, I am also unable to build the sdk currently, but due to node errors. Are there specific environmental settings to be able to build the SDK now?

[INFO] Installed npm locally.
[INFO] Running 'npm install --no-optional' in /home/mseaton/code/github/openmrs/openmrs-sdk/integration-tests/target/test-classes/integration-test/buildIT
[WARNING] npm WARN deprecated extract-text-webpack-plugin@1.0.1: Deprecated. Please use
[WARNING] npm WARN deprecated html-webpack-plugin@2.30.1: out of support
[WARNING] npm WARN deprecated babel-preset-es2015@6.24.1: 🙌  Thanks for using Babel: we recommend using babel-preset-env now: please read to update!
[WARNING] npm WARN deprecated core-js@2.6.12: core-js@<3.3 is no longer maintained and not recommended for usage due to the number of issues. Because of the V8 engine whims, feature detection in old core-js versions could cause a slowdown up to 100x even if nothing is polyfilled. Please, upgrade your dependencies to the actual version of core-js.
[WARNING] npm WARN deprecated chokidar@2.1.8: Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies.
[ERROR] npm ERR! Linux 5.8.0-53-generic
[ERROR] npm ERR! argv "/home/mseaton/code/github/openmrs/openmrs-sdk/integration-tests/target/test-classes/integration-test/buildIT/node/node" "/home/mseaton/code/github/openmrs/openmrs-sdk/integration-tests/target/test-classes/integration-test/buildIT/node/node_modules/npm/bin/npm-cli.js" "install" "--no-optional"
[ERROR] npm ERR! node v6.17.1
[ERROR] npm ERR! npm  v3.10.10
[ERROR] npm ERR! notsup Unsupported engine for browser-sync-client@2.26.14: wanted: {"node":">=8.0.0"} (current: {"node":"6.17.1","npm":"3.10.10"})
[ERROR] npm ERR! notsup Not compatible with your version of node/npm: browser-sync-client@2.26.14
[ERROR] npm ERR! notsup Not compatible with your version of node/npm: browser-sync-client@2.26.14
[ERROR] npm ERR! notsup Required: {"node":">=8.0.0"}
[ERROR] npm ERR! notsup Actual:   {"npm":"3.10.10","node":"6.17.1"}
[ERROR] npm ERR! Please include the following file with any support request:
[ERROR] npm ERR!     /home/mseaton/code/github/openmrs/openmrs-sdk/integration-tests/target/test-classes/integration-test/buildIT/npm-debug.log
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  9.361 s
[INFO] Finished at: 2021-05-25T09:05:58-04:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.openmrs.maven.plugins:openmrs-sdk-maven-plugin:4.0.1-SNAPSHOT:build (default-cli) on project owa: Unable to execute mojo: Failed to run task: 'npm install --no-optional' failed. (error code 1) -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.openmrs.maven.plugins:openmrs-sdk-maven-plugin:4.0.1-SNAPSHOT:build (default-cli) on project owa: Unable to execute mojo

Something in the refactoring broke this test. You’re absolutely right that 1.11.5 version of the platform distro doesn’t exist. AFAICT it never existed.

When I step-debug through the current SDK where this test passes, it actually downloads the WAR file for org.openmrs.web:openmrs-webapp:1.11.5, which does exist, rather that the file in org.openmrs.distro:platform:1.11.5.

Although somewhere around platform 2.0, it looks like a WAR file was bundled along side the distro release, the sole contents of the 1.11.7 “distro” jar are a file called with these contents:


@mseaton Apparently since this commit we accidentally require a minimum version of Node 8. I suppose we could try reverting that to pin browser-sync 2.11.1 if Node 6 support is still required…

1 Like

OK, @ibacher / @bistenes et al, I tracked this down.

Basically, I am running the latest node and npm, and this was still failing for me. However, I’m running on Ubuntu and use nvm as the means by which I install both node and npm. You can see my setup here:

$ npm -v
$ node -v

I was scratching my head over this, and did a bunch of googling. What I found is that there are 2 different issues that, together, led to this issue.

What the SDK does when trying to build an OWA is to:

  1. See if the system has node & npm installed at appropriate versions, and if so, use them
  2. If not, install specific local versions of node and npm and use those

In my case, the first issue is that the SDK was not finding my local node and npm. The reason for this is that I have these packages installed via nvm. Apparently, nvm takes over control of setting the right node and npm executables on the PATH, based on whatever version it is told to use. But it does not do this via a mechanism that everything can see. The upshot is that although these executables are found in my path in a bash shell, they are not found when invoking a new local process via a Java ProcessBuilder ( as we do in OwaHelper.getSystemNodeVersion() and OwaHelper.getSystemNpmVersion() ). Thus, for anyone running node / npm who installed them via nvm, no system versions will be found or used.

So then the system falls back to the locally installed versions, and here is where there was an issue in the code. As you mentioned above, since a certain commit we have required Node 8. However, the local version of node that the SDK installed was set to 6.4.0. When I updated this to the latest version, my build now passes.

Ticketed here:

PR here: SDK-278: Local npm and node versions are incompatible with latest code by mseaton · Pull Request #184 · openmrs/openmrs-sdk · GitHub



@bistenes - looking again at your original error report here, and also thinking about what @ibacher said, I suspect that your refactoring is leading to this error. I think you should look at two possibilities:

  1. The original code was wrong, and your refactoring exposed it, and we just need to fix the tests

  2. The original code was correct, there was some special-case logic in place to say “if you ask for a platform version, and no distribution is found with that version, then simply download the war file with that version if it is available”, which seems to be what the test is expecting, and your refactoring likely no longer handles.


Yeah, that seems right, @mseaton .

My guess is that it’s a special case, and that the code before was correct. Platform 1.11.5 would seem to have been chosen intentionally as a version that isn’t present as org.openmrs.distro:platform. Any idea who I should talk to to validate that? The code was written by a combination of @raff , @adamg , and @gutkowski .

Thanks for spelling out what case (2) would look like, I wasn’t quite sure how that would be supposed to work from looking at the code.

I actually think 1.11.5 was chosen because it was the current stable release at the time the code was written… That test is substantially the same as it was when originally written (June 2016).

It’s also the default version the SDK tries to install, which may be why it’s tested in particular.

Okay cool. Does it make sense that it should be downloading the war file version?

@bistenes yes because the file associated with that likely has war 1.11.5 as the specified openmrs version. I don’t really understand why it is not expecting a modules folder to be present though, as I expect 1.11.5 also included the module.


1 Like

At some point, it does need to download the WAR file, so yes.

Here’s what I can make of the current flow of the Setup operation:

In the current code if no distro properties are specified, then it downloads the disto Jar for the specified version just to get the file from it (happens here).

Confusingly (to me at any rate) it then calls moduleInstaller.installCoreModules(), which is the point that actually downloads the WAR file.

moduleInstaller.installCoreModules() then gets the webapp WAR added either from the properties file or, more or less, as a hard-coded requirement.

I don’t know if that’s remotely helpful.

1 Like