2022-01-24 TAC: Making decisions OpenMRS Packaging

Development
,
1

Agenda for this Monday (24 January): Making decisions on OpenMRS Packaging conventions

We’ll review our Draft schema for OpenMRS Packages and work through some of the decision points. For example:

  • What types of assets can be in a package?
  • What string format convention do we use when referring to an asset (ESM, omod, metadata, etc.)?
  • Which versioning format do we use?
  • How should local assets (whether part of a package or downloaded during a build process) be organized?

Where: om.rs/zoomtac

When: Monday at 3pm UTC / 7am PST / 10am EST / 4pm CEST / 6pm EAT / 8:30pm IST

/cc @ibacher @mksd @eudson @mayanja @mseaton @mogoodrich @bistenes @jdick @ssmusoke @grace @raff & please CC others you think would be able to help us in creating initial conventions for packaging.

3 Likes
2

I have read through the document and have the following thoughts on approach

  1. OpenMRS is a Java based platform and backend, so we need to stick with the Java based tools for building and packaging, in this case Maven - there are plugins for integrating with NPM

  2. The front end technologies are going to change every 2-3 years, yet the backend is not going to change (now there is a push towards npm-less front end development) back to our good old days of copying a JS library into your assets

  3. Leverage OpenMRS SDK to build and pull everything together, the backend omods and the front end-packaging - again delegating to maven then npm for front end assets

  4. I know there is a push among the front end driven teams to move away from Maven and try something new, however given #2 above its imperative to stick to the backend tools and provide front-end extensions

IMO keep the omods and pull in the esms just like OWAs about 3-4 years ago

Quote: The more things change, the more they remain the same

1 Like