Switch OpenMRS release version for EMRAPI?

Development
1

Hi,

The emrapi module now points to OpenMRS release 1.9.9 and we have conditional resources specified for 1.10 / 1.11 and 1.12. Its been a bit difficult to maintain this as it introduces duplicates.

Is it an option to switch the OpenMRS version?

-Shruthi

2

@shruthidipali, would you like to bump the supported version from 1.9.9 to 1.10?

Could you explain your difficulties? Maybe we could address them.

3

Looking quickly at the code, I see what you mean.

It looks like all of the code we have in the api-1.10 is duplicated in api-1.11 and api-1.12. Why are we doing this? This can’t be the right way, is it @raff?

Mike

4

@raff I was hoping to address the exact problem @mseaton is talking about. Is there a better way to do this? It’ll be great to understand how other OpenMRS modules support backward compatibility.

-Shruthi

5

Shruthi, did you get a chance to look at this? https://wiki.openmrs.org/display/docs/Supporting+different+OpenMRS+versions

6

@dkayiwa Thanks for sharing this. Hadn’t seen this earlier.

We could try using @OpenmrsProfile to avoid duplicate code.

-Shruthi

7

@shruthidipali, I’ve cleaned things up for you in https://issues.openmrs.org/browse/EA-86

Please review and close :slight_smile:

8

Hey @raff

Sorry for responding late! I had to revert your code because it broke the freeText functionality we had implemented for 1.12 version of OpenMRS and we were very close to giving out a release build. I’ll definitely have a look and try to understand the changes better.

Thanks a lot for taking the time out and doing this!

-Shruthi

9

Cool. I’ve added a comment on the issue about the revert. Feel free to pick it up and reapply the change when you have some time to work on that. You got the idea.

10

@shruthidipali, @vinay, do we have a bit more breathing room before the next Bahmni release, to redo this refactoring and work out any problems?

11

For what it’s worth, I’d been having trouble running the 1.11 tests (specifically EmrEncounterController_1_11_Test), which I assume might be do the setup issues… this somehow magically cleared up, but it had been a blocker for me in terms of making sure I write adequately tests for a (small) change I want to make to the EncounterTransaction.

So it would be good to get these resolved!

Mark

12

@darius It would be great if we can have a call to talk about this. Its an issue from circular dependencies between OpenMRS modules.

We plan to pick up some analysis/development on some parts in March.

  • remove metadatasharing by moving some utility methods to the metadatadeploy module instead
  • remove providermanagment by adding a “provider type” in openmrs-core
  • event and reporting could be aware-of dependencies if you really want

-Shruthi

13

Happy to have a call to discuss this, but I wonder if it would be most efficient if someone can summarize the actual problem, prior to having a call. (From messages earlier this thread I guess that @raff did 90(?)% of the refactoring, but missed something related to 1.12, so we reverted that code. It would be helpful to see what actually broke there.)

For the specific refactorings you mention in bullet points, I have gone ahead and created JIRA tickets for the first two: