OWAs and dependencies

Development
1

Continuing the discussion from Order Entry UI OWA 1.0.0-beta released!:

I believe that this has come up in other threads, but in the context of the orderentryui owa beta release, I wanted to raise the topic again here for design/discussion.

For orderentryui, the team has indicated that this requires the following modules: Webservices REST (v2.23.0), Reference MetaData (2.7.2), MetaData Deploy (1.11.0), Order Entry UI (v1.0.0). I assume it also likely requires a certain version of OpenMRS Core (presumably at least 1.10, possibly higher once we start introducing Order Sets).

Unlike for modules, there is not a way that I’m aware of for an OWA author to specify in the the OWA configuration what platform requirements exist for it to function, or what it has been tested against. As we continue to scale up OWA development, this is a limitation we should try to address.

I’m interested in thoughts on how we might approach this, and if this is already ticketed or not. It would be great to prioritize this and some related functionality in the near term.

Best, Mike

2

I think we might already have some custom stuff in the manifest, so I guess it could go there.

3

+1 to Pascal’s comment. (And I don’t even think there’s a need to discuss whether this is required; it obviously is.)

We should add something to the manifest, under activities.openmrs that indicates requirements, maybe like:

requirements: [
    {module: "org.openmrs.module.reporting", version: "1.0"},
    {coreVersion: "2.1.3"}
]
1 Like
4

@darius and @pascal thanks for the responses. I have created this ticket to try to get this defined and underway as a possible enhancement. I think this needs a little more fleshing out, so I put it into Needs Design. I think the design proposed above makes sense, though as I write in the ticket, I think we need to support a bit more complexity about version ranges that might be supported for a given dependency, particularly for core versions supported.

5

Perhaps the version could be something like what is present in the package.json files used by yarn and npm. This might put some constraints on future version numbers as it requires backward compatibility when minor numbers are changed.

An alternate would be a list of compatible versions, rather than a single one. But this means that the OWA would need to be updated if there was a minor (say bug release) to one of its dependencies, which does not seem a very good idea.

6

Thanks @mseaton for bringing this up. I have labeled it as a community priority ticket.

Did you mean that we need to support more version range complexity than what is currently provided for modules?

7

@mseaton, thanks for creating OWA-95 to add the ability to specify core & module versions to OWA manifests. I’ve tried to revise the ticket description to take into account your comments and @darius’ response. Could you take a peek at the ticket and, if you agree, change it to ready for work (or let me know and I will). Otherwise, if you think we still need design discussion, let me know and we’ll get it into the queue.

8

That’s great @burke - thanks for that review. It looks good to me, I think we are all on the same page. Moved it into Ready for Work.

Best, Mike