Errors while building OpenMRS-CORE

Hallo guys I am working on this issue Log in - OpenMRS Issues. I cloned the Openmrs-core on my machine and without making any changes I tried to build the package by running mvn-clean-install.

But I got these two errors anyone who can help me understand them better.

[ERROR] Failures: [ERROR] HibernateAlertDAOTest.getAlerts_shouldReturnAllAlertsWhenUserIsSpecified:69 expected: <0> but was: <1> [ERROR] HibernateAlertDAOTest.getAllAlerts_shouldReturnOnlyNonExpiredAllerts:63 expected: <0> but was: <1> [INFO] [ERROR] Tests run: 4350, Failures: 2, Errors: 0, Skipped: 36 [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary for OpenMRS 2.5.0-SNAPSHOT: [INFO] [INFO] OpenMRS … SUCCESS [06:20 min] [INFO] openmrs-tools … SUCCESS [03:31 min] [INFO] openmrs-test … SUCCESS [01:22 min] [INFO] openmrs-api … FAILURE [24:07 min] [INFO] openmrs-web … SKIPPED [INFO] openmrs-webapp … SKIPPED [INFO] openmrs-liquibase … SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] -----------------------------------------------------

@jwnasambu @dkayiwa

Oh sorry @suubi7 . Kindly share the entire error log you are getting using pastebin please!

@jwnasambu here is the error log. Errors while building OpenMRS-CORE -

running mvn clean install on a freshly cloned OpenMRS core seems to build OpenMRS 2.7.0-SNAPSHOT out of the box.

Reactor Summary for OpenMRS 2.7.0-SNAPSHOT:

Given the error it seems as though its not apparently related to the method in EncounterService causing extreme slowness nor the tests for the EncounterService that located in the org.openmrs.api.EncounterServiceTest class. But rather the errors you are seeing are from unit tests because they expected a certain result but got a different one;

  • HibernateAlertDAOTest.getAlerts_shouldReturnAllAlertsWhenUserIsSpecified: This test was expecting to receive 0 alerts but actually received 1.
  • HibernateAlertDAOTest.getAllAlerts_shouldReturnOnlyNonExpiredAllerts: This test was also expecting to receive 0 alerts but actually received 1.

You may need to investigate the code and the tests to determine what is causing the unexpected behavior.

But again if this is not related to the issue, i would suggest you provide logs for any errors or warnings related to the EncounterService and then do profiling to determine the methods and operations related to the slowness. Am not sure about the tools OpenMRS uses here but it would be important to investigate and compare the performance differences .

very important to look at comments on this;



@dkayiwa @ibacher

1 Like

Thank you at @thembo. Yes I worked on the EncounterService delay here is the pull request Issue with method in EncounterService causing extreme slowness by suubi-joshua · Pull Request #4273 · openmrs/openmrs-core · GitHub.

Am still trying to investigate the the two errors I got but also how to test if what I actually did reduces the slowness.

sure! Did you find tools for best practice to get performance metrics?

@thembo Do you have some recommendations

/cc: @ibacher @dkayiwa

@jwnasambu @thembo42 @dkayiwa Hallo I worked around these errors by changing the value of the AssertEquals to 0 in the methods HibernateAlertDAOTest.getAllAlerts_shouldReturnOnlyNonExpiredAllerts() and HibernateAlertDAOTest.getAlerts_shouldReturnAllAlertsWhenUserIsSpecified().

After that I run mvn clean install and the build was successful.

Though my question is why were these methods coded to test if AssertEquals equals 1?

hi @suubi7

i doubt changing the value of the Assert statement is better solution as it may reduce the robustness of the test case in the future…

Anyway, i suppose the tests were originally written assuming that there would always be at least one alert in the test database . technically;

if there is only one alert returned by the method being tested, the expectation could be that it should not be expired or it should belong to the user that was specified.

cc/ @ibacher @dkayiwa

Exactly AM still trying to figure out the reason why this came up at initial build of the core.

Are you getting the error before or after making the changes?

@suubi7 Am not certain if you got a chance to look at the previous comments on the ticket especially the one made by Darius. The changes to be made are supposed to be on 2.x branch. To switch to 2.x branch on your forked repo kindly follow this steps:

git fetch --all (To fetch all branches from all remotes)
git branch --all (To list all the branches you have)
git checkout 2.x (Ensure its among the listed branches)
git checkout -b TRUNK-5362
1 Like

@jwnasambu thanks I had not taken notice of Darius’s comment. This shades new light let me work on that.

Also take your time to understand the discussion on this link Method in EncounterService is causing extreme slowness in production - #9 by mogoodrich.

1 Like

@jwnasambu okay sure thing.

@jwnasambu I got the error before making the changes.

@suubi7 what does this command return? mvn -v

@kdaud It returns the version of maven I have on my machine

Is it connected to the problem.

Can you try: git reset --hard

Then: git clean -df

And pull the latest upstream changes.

Finally compile again.

1 Like